Search logs:

channel logs for 2004 - 2010 are archived at ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present

Monday, 20 June 2022

04:27:00 <geist> Huh TIL that `hexdump` has a whole formatting mechanism where youcan give it printf style output string
04:27:00 <geist> It’s pretty nice
04:27:00 <zid`> I knew it had a bunch of options, not sure I knew about the printf one
04:32:00 <geist> Yeah. (Dunno why I got bumped there)
04:36:00 <zid`> because you were on the wrong server
04:36:00 <zid`> wallops have been going out to tell you to change because they're starting em
04:36:00 <zid`> re
04:50:00 <geist> Ah i see. Well I’m coming in via irccloud so i can’t decide what server it connects to
04:50:00 <geist> Just had to take the bump and let it reconn
04:51:00 <kazinsal_> yeah, same
04:51:00 <geist> random thing i think I’m going to settle in for the night: write a 6800 emulator for an Altair680
04:52:00 <geist> Why? I dunno, but i already have al title emulator project and it’s easy to add another cpu to it, and the 6800 is like a one-evening project
04:52:00 <zid`> I was thinking of rewriting mine but I haven't worked up the gumption
05:24:00 <kazinsal> gah. why does pidgin still not have a dark mode on windows in 2022
06:58:00 <FatAlbert> why do you use windows in 2022
06:58:00 <FatAlbert> ?
06:59:00 <mrvn> because if I remove the windows and it rains then my monitor gets wet.
06:59:00 <mrvn> *duck*
07:02:00 <vdamewood> mrvn: It's a fair enough answer to such a question.
07:28:00 <FatAlbert> how much time it take before WW3?
07:29:00 <FatAlbert> i think 2 years from now, hell gonna break loose
07:30:00 <FatAlbert> i want it because it will be egood for my interests
07:30:00 <klange> I don't think that's appropriate topic of discussion for this channel, unless you think the spark is going to be over operating system choices.
07:31:00 <FatAlbert> when ~80% of a nation is dead there will be what i call social reset
07:31:00 <FatAlbert> i just hope i won't be part of these 80%
07:31:00 * vdamewood pots away his troll food.
07:31:00 <vdamewood> puts*
07:33:00 <FatAlbert> everyone will have a chacne to start all over
07:33:00 <FatAlbert> also after a war ... all bad blood has been cleared
07:33:00 <FatAlbert> it's a new life !
07:34:00 <vdamewood> I think I want to fit my entire kernel in the lower 640k of memory.
07:34:00 <FatAlbert> in essence we are getting close to the new 60s or 70s ... isn't that beautiful ?
07:35:00 <clever> vdamewood: some of my kernel builds run on just 128kb of L2 cache, and not even touching ram
07:36:00 <mrvn> FatAlbert: unless it's an AI uprising I have <20% confidence of your survival.
07:38:00 <FatAlbert> wow so little faith ...
07:38:00 <klange> what if it _is_ an AI uprising?
07:39:00 <FatAlbert> most of people who have been thorough half of what i have in life are either committed suicide in jail or are on drugs somewhere
07:39:00 <mrvn> The AI might keep him around for some menial programming work. Or target nerds with a vengance so they don't write a virtus to take it down. Uncertain.
07:39:00 <mrvn> -t
07:40:00 <FatAlbert> also
07:40:00 <FatAlbert> i have the power of invisibility ... what do you think i won't survive ?
07:40:00 <FatAlbert> why
07:40:00 <vdamewood> mrvn: Maybe an "I have no mouth, and I must scream" scenario.
07:41:00 <mrvn> FatAlbert: you will be run over by an automated truck on the first day.
07:41:00 <FatAlbert> i see the light at the end of the tunnel ...
07:41:00 <FatAlbert> it's a beautiful time .. and i have no intention of not be there
07:45:00 <psykose> >60s
07:45:00 <psykose> >good
07:45:00 <psykose> epic bait
07:47:00 <FatAlbert> i sometimes wonder, how death will eventually find me
07:48:00 <FatAlbert> a survivor like me.
07:48:00 <FatAlbert> are you guys also wonder it ?
07:49:00 <kazinsal> I more often wonder what exactly it is about this hobby that attracts the weirdest people
07:49:00 <FatAlbert> by wierdest people you mean me, ok, but what hobby are we talking about ?
07:50:00 <FatAlbert> anyway
07:52:00 <FatAlbert> i just hope ill pass on these genes. someone down the road might make better use of it
08:19:00 <mrvn>
08:19:00 <bslsk05> ​xkcd - Machine Learning Captcha
08:21:00 <clever> heh
08:22:00 <FatAlbert> mrvn: what was your choices ?
08:26:00 <FatAlbert> where do you run for ?
08:27:00 <mrvn> as if I would tell an AI
09:00:00 <FatAlbert> what
11:12:00 <Arsen> on gcc, is there an attribute for disabling -fbuiltins on just one function (for the purposes of implementing memset etc)
11:14:00 <heat> usually you disable it in the files themselves
11:14:00 <heat> makes very little sense to disable it in one
11:14:00 <psykose> -fno-builtin-function exists, not sure if just matches by name
11:14:00 <heat> but I suppose you could do some pragma shenanigans to get that?
11:15:00 <Arsen> yeah, could do a file-by-file too
11:15:00 <Arsen> I don't think there's a pragma for this
11:16:00 <heat>
11:16:00 <bslsk05> ​ Function Specific Option Pragmas (Using the GNU Compiler Collection (GCC))
11:16:00 <heat> I was thinking of those
11:16:00 <heat> but i dunno if it works with fbuiltin
11:17:00 <Arsen> "Each function that is defined after this point is treated as if it had been declared with one optimize(string) attribute for each string argument." time to see what optimize is
11:17:00 <Arsen> hah that's it, you're a genius!
11:17:00 <Arsen> thanks heat
11:17:00 <klange> any -f option, without the -f
11:18:00 <heat> thank you arsen, I know
11:18:00 <heat> my intellect knows no bounds
11:19:00 <Arsen> nor does your modesty :^)
11:19:00 <heat> my phd thesis will be based on random GCC tidbits and facts
11:19:00 <heat> :P
11:20:00 <klange> (though the -fno-builtin* stuff isn't listed in the "options that control optimization" section, so whether or not that actually works is... unknown, have fun!)
11:20:00 <Andrew> zid`: the register points to a memory locaation eight-bytes long (64-bit) that points to a disk location to store the weather
11:21:00 <heat> we're doing pmem?
11:21:00 <Arsen> oh true, hmm
11:21:00 <Arsen> well, time for a test I suppose
11:21:00 <Arsen> alternatively, I'll just build these files into a static lib without builtins and link that
11:22:00 <heat> IT DOES NOT WORK
11:25:00 <j`ey> clever: having trouble with -serial pty. I run qemu with that, and then 'picocom /dev/pts/8', but I dont see any output, any ideas?
11:26:00 <Arsen> klange: indeed, builtin is not permitted there
11:26:00 <Arsen> unfortunate
11:36:00 <heat> j`ey, just tried with screen and it works here
11:37:00 <heat> I get a /dev/modem: No such file or directory with minicom
11:38:00 <j`ey> screen doesnt get me any output either
11:38:00 <heat> well, you're not getting any old output
11:39:00 <j`ey> ok screen does work actually
11:39:00 <heat> praise be gnu and gnu/linux, or as I've recently taken to call it, GNU plus Linux
11:40:00 <j`ey> doesnt work with --accel kvm..
11:40:00 <heat> works here
11:44:00 <heat>
11:44:00 <heat> qemu-system-x86_64 -serial pty -cdrom ~/Downloads/archlinux-2022.03.01-x86_64.iso --enable-kvm -m 1G
11:44:00 <heat> which I use, btw
11:45:00 <psykose> can't tell anything happening on that screen, is that windows
11:45:00 <j`ey> weird
11:45:00 <zid`> Your call is very important to us. Please wait for an operator to handle your call.
11:50:00 <heat> psykose, GNU hurd
11:50:00 <psykose> windows 2!
11:51:00 <heat> j`ey, maybe its linux's fault
11:51:00 <heat> i know it's sometimes a bit fucky with serial ports
11:51:00 <j`ey> but this is on the 'other side'.. unless you mean my host linux?
11:52:00 <heat> the guest
11:52:00 <j`ey> it shouldnt know how the serial is being displayed
11:53:00 <heat> yes, thats not the point
11:53:00 <heat> are you passing the correct console=ttyS0,<baud>
11:53:00 <heat> are you sure that systemd/your init system is picking up the tty and setting up a getty
11:53:00 <j`ey> why would kvm or not change that?
11:54:00 <heat> it wouldn't
11:54:00 <heat> unless you've got a really weird setup
11:55:00 <heat> or a really weird problem ofc
11:56:00 <j`ey> hmm
12:17:00 <ddevault> hrpmh
12:17:00 <ddevault> rewrote my syscall handler, works, but interrupts stopped working
12:42:00 <ddevault> there we go
12:43:00 <ddevault> ✓ yield
13:24:00 <FatAlbert> what is Cmd key in vscode ?
13:24:00 <FatAlbert> i usually use vim but i decided i want to try vscode
13:25:00 <FatAlbert> but hey at least im getting closer to closer being on-topic
13:25:00 <FatAlbert> :)
13:25:00 <FatAlbert> s/to/and
13:25:00 <ddevault> how does one patch KDE2 under FreeBSD
13:26:00 <heat> (ctrl/cmd)+shift+p should let you input commands if that's what you want
13:26:00 <FatAlbert> heat: Cmd == ctrl ?
13:26:00 <heat> FatAlbert, pretty sure you have vim binding extensions too
13:26:00 <heat> idk, context?
13:27:00 <heat> ddevault, erm, context?
13:27:00 <heat> yall need to give out some of dat context
13:30:00 <ddevault> an old russian meme
13:30:00 <ddevault> pointing out that the question was off-topic
13:30:00 <ddevault> "hi, is this an anime channel" "yes" "how does one patch KDE2 under FreeBSD"
13:35:00 <j`ey> hunter2
13:35:00 <j`ey> heat: someone running kvm/arm in qemu cant repro :<
13:36:00 <j`ey> (I say 'someone', that someone is the kvm arm maintainer :P)
13:40:00 <FatAlbert> j`ey: sounds to me like your in love
13:40:00 <j`ey> i am
13:40:00 <heat> j`ey, can't repro your bug or my success?
13:40:00 <heat> he's in love with me
13:40:00 <heat> my arch usage is charming
13:40:00 <j`ey> cant repro my bug
13:40:00 <j`ey> heat: im in love with you, btw
13:40:00 <FatAlbert> he's in love with the kvm arm maintainer
13:40:00 <heat> :D
13:41:00 <FatAlbert> i wonder if there are girls doing all these low level stuff in the industry
13:41:00 <heat> some
13:42:00 <heat> j`ey, i'm on qemu 7.0.0
13:42:00 <j`ey> same
13:42:00 <FatAlbert> 90% of the girls in the industry i bet they are either general programmers or sys admins
13:42:00 <heat> wtf
13:42:00 <j`ey> i assume im doing something dumb
13:42:00 <heat> have you tried my exact command line
13:42:00 <heat> with $your_favourite_distro
13:42:00 <j`ey> no because arm
13:43:00 <heat> ubuntu server arm64?
13:43:00 <FatAlbert> arm of king leoric
13:43:00 <heat> also trying out x86_64 might be a way to go
13:43:00 <heat> I doubt the behavior varies based on the architecture
13:43:00 <j`ey> yes but then i'd be trying it on a different computer etc
13:44:00 <FatAlbert> seems like both of you need a little bit of GeDaMo
13:44:00 <heat> computer is hard
13:44:00 <heat> i like rock
13:44:00 <heat> rock good
13:45:00 <FatAlbert> hes the judge jury and executioner in #osdev
13:46:00 <FatAlbert> GeDaMo: show yourself
13:46:00 <j`ey> wait.. i think it's just fast with kvm lol
13:47:00 <j`ey> omg this might really just be silly
13:47:00 <heat> -_-
13:47:00 <heat> you dare bother the mighty kvm arm maintainer for this
13:47:00 <j`ey> lol
13:48:00 <j`ey> i had: screen /dev/pts/n ; sleep 1 ; ..
13:48:00 <j`ey> but all the output it printed was so fast with kvm, it was always missed
13:48:00 <zid`> lol that'd do it
13:49:00 <zid`> how *do* you launch it so that it works I wonder
13:49:00 <j`ey> remove the sleep 1 :P
13:54:00 <zid`> that's still racy
13:54:00 <zid`> just a lot easier to win
13:55:00 <heat> you create the pty beforehand and use the regular qemu tty code I assume
14:04:00 <FatAlbert> heat: wow thanks
14:04:00 <FatAlbert> vscode is so much cooler with vim style
14:05:00 <FatAlbert> i didn't fully tested it yet ... but it seems like the best of both world
14:06:00 <FatAlbert> see ...
14:06:00 <FatAlbert> that's why im hanging out with you guys ... eventually someone will say something i understadn
14:06:00 <FatAlbert> and it's usually valuable
14:08:00 <FatAlbert> insane
14:13:00 <FatAlbert> heat: one thing ... ican't seem to integrate my init.vim and neovim plugins in vscode
14:13:00 <FatAlbert> settings.json includes
14:13:00 <FatAlbert>
14:13:00 <bslsk05> ​ View paste VFHA
14:17:00 <FatAlbert> ill do my own research
14:22:00 <kingoffrance> "how does one patch KDE2 under FreeBSD" electrobsd has that on the faq i believe "I don't"
14:39:00 <FatAlbert> king of france ask you a question, so you either asnwer you don't know or help
14:41:00 <kingoffrance> ? i dont know vscode. vim :D
14:43:00 <kingoffrance> in the immortal words of another chatter "why you always configure? just make!" i dont mess with my editor much, just edit!
14:48:00 <zid`> I think I am just a better engineer than most people, I always manage to reassemble most things with fewer screws used than I started with
15:09:00 <heat> FatAlbert, it's just a keybindings plugin
15:09:00 <heat> it's not actually vim lol
15:13:00 <FatAlbert> yeah it's said in the charter it's a vim emulation
15:13:00 <FatAlbert> so i thought what if ..
15:13:00 <ddevault> I bet I can have doom running within six weeks
15:13:00 <FatAlbert> ddevault: you can do it right now
15:14:00 <ddevault> (on my kernel)
15:14:00 <GeDaMo> Port DOSBox to your kernel and get all sorts of games running :P
15:16:00 <FatAlbert> is porting requires reverse engineering ?
15:16:00 <ddevault> well, sometimes
15:17:00 * FatAlbert runs away
15:18:00 <FatAlbert> i always wanted to get into reverse engineering ...
15:19:00 <FatAlbert> what type of kernel you built ddevault
15:19:00 <FatAlbert> mono or micro
15:20:00 <ddevault> micro
15:21:00 <FatAlbert> did you optimized it toward gaming or you just want to run doom in it
15:21:00 <ddevault> the latter
15:27:00 <FatAlbert> so ...
15:27:00 <FatAlbert> you have my best wishes :)
15:27:00 <ddevault> thank you
15:27:00 <FatAlbert> yw
15:27:00 <j`ey> ddevault: 6 weeks is 1 aug
15:28:00 <ddevault> your mathemtical skills are remarkable
15:28:00 <j`ey> ty
15:28:00 <j`ey> i wasnt sure if that was intentional or not
15:31:00 <zid`> how many weeks is an ak-47
15:31:00 <ddevault> 47
15:31:00 <ddevault> the hint is in the name
15:35:00 <psykose> but maybe that's 47 days
15:35:00 <ddevault> oh hey psykose
15:35:00 <ddevault> thanks for the quick reviews on aports this morning
15:36:00 <psykose> :)
15:38:00 <psykose> was still meant to be merged or is it just non-esr
15:38:00 <bslsk05> ​ testing/himitsu-firefox-esr: new aport (!35439) · Merge requests · alpine / aports · GitLab
15:38:00 <ddevault> can be closed
15:39:00 <Ermine> Not the best place to discuss that but ok
15:39:00 <psykose> just a little lazy to tab buffers :p
15:39:00 <psykose> and you can't tell me this place is ever on topic
15:41:00 <j`ey> on the odd occasion
16:44:00 <heat> I'd just like to interject for a moment
16:55:00 * kingoffrance hands heat the conch
16:56:00 <kingoffrance> i believe that was more or less token ring
17:02:00 <zid`> sorry for interrupting you heat but
17:14:00 <mrvn> oh no, the token must have fallen out of the ring.
17:15:00 <mrvn>
17:15:00 <bslsk05> ​ Dilbert: Token-ring
18:32:00 <FatAlbert> she got a smile that it seems to em
18:33:00 <FatAlbert> heat: it turns out to be that vscodevim also includes easyomtion which is the vim plugin i wanted for vscode :)
18:36:00 <sbalmos> heat was trying cooperative channel chatter. should've just preempted. ;) everyone gets a channel quantum to sa... *interrupted*
19:04:00 * geist yawns
19:04:00 <geist> good afternoon folks!
19:07:00 * mjg_ yawns back
19:08:00 * mjg_ codes something for fan for the first time in weeks
19:08:00 <mjg_> fun even
19:08:00 <mjg_> upside of slack: i could have edited the above
19:29:00 <geist> oh cool
19:52:00 <sbalmos> *yawn* is it Friday yet?
19:53:00 <psykose> yeah
19:54:00 <sbalmos> if (!time::current_day()->day_of_week == time::DayOfWeek::Friday) { reality::current_mental_state->block(); }
20:03:00 <heat> SIGCONT
20:03:00 <heat> What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
20:05:00 <sbalmos> heat: SIGCONT handler is a while-not-Friday loop :P
20:18:00 <geist> reading the xtensa arch manual, it's fairly interesting bt nothing to write home about
20:18:00 <geist> the register window is kinda funny, so it has an odd ABI thats definitely strange
20:19:00 <geist> though not so much to people that are used to register windows at least
20:20:00 <sbalmos> never heard of it. another neat little core?
20:21:00 <heat> i think xtensa is pretty old lol
20:21:00 <geist> sort of. it's a synthesizable core from Cadence. Mostly aware of it because it is in ESP32, though ESP32 is moving towards riscv
20:21:00 <geist> but doug16k was fiddling wit it the other day so got me to looking up the arch manual
20:22:00 <sbalmos> ah, yeah okay I remember it being mentioned now
20:22:00 <geist> otherwise mostly a regular looking risc cpu with some DSP extensions:
20:23:00 <geist> 16 registers, can rotate by 4 8 or 12 on call entry (that's the call4/call8/call12) so there's some interesting arg passing and return going on there
20:23:00 <geist> ie, in that case it puts args in a10/11/12 and uses a call8, which rotates the registers down by 8, so the incoming args are in a2/3/4
20:24:00 <geist> a0/a1 are always the return address + stack pointer, which gets copied in the entry basically, so yo uget a fresh copy of the return address and stack
20:24:00 <geist> the N of how far the register window was rotated is orred into the saved PC in a0 (top 2 bits it seems)
20:25:00 <geist> that's how the ret instruction knows how much register window to uncover
20:25:00 <geist> (16 registers, so a0-a15)
20:25:00 <sbalmos> oh fun
20:29:00 <geist> anyway, just a little mystery i wanted to solve. it's not that interesting, but i like different cpu architectures just cause
20:30:00 <sbalmos> in the meantime, I've been shamefully hanging my head over the weekend and today, trying to concretely remind myself exactly how a thread blocks, waits, is woken up, etc. Obviously know the theory. Just down to concrete impl stuff. Took far too long to really boil it down to thread.state = State::Blocked; scheduler::switch();
20:30:00 <sbalmos> catching up on a hobby you wanted to get into 20 years ago, right out of college, is hell.
20:30:00 <geist> usually my strategy is the state is mostly contined in whether or not the thread is 'discoverable' by the scheduler or not
20:31:00 <geist> ie, the thread structure is in one list most of the time (or running)
20:31:00 <sbalmos> ya
20:31:00 <geist> if it's in the scheduler list it's ready to run, if it's sitting on a wait queue, it's blocked
20:31:00 <geist> if it's running it's 'owned' by the cpu
20:31:00 <geist> only time it may be in no list at all is when it's sleeping, or suspended, but theres other tracking data to get it back i nto the run queue
20:32:00 <sbalmos> it was more fundamental than that. The whole idea of a blocking read basically boiling down to a driver literally yielding, like cooperative multitasking
20:32:00 <geist> in that sort of design the state enum on the thread is moslty there so you can quickly determine what to do with it when you run an operation against it
20:32:00 <geist> well, i think with a wait queue style design the whole idea of a blocking read is the driver provides/has a primitive to put the current thread on until some point in the future that the driver wakes it up
20:33:00 <sbalmos> right
20:33:00 <geist> so the thread just appears blocked on something, but the something is the driver's responsibility
20:34:00 <sbalmos> gets into mutexes and poll-waiters, etc. but from the fundamental perspective, it gets into the mutex now being the point that literally calls yield
20:34:00 <geist> here's a fairly trivial example out of my code: is when the virtio-blk driver makes a request and then just tosses the current thread on an event_t (which is basically a simple wrapper around a wait queue)
20:34:00 <bslsk05> ​ lk/virtio-block.c at master · littlekernel/lk · GitHub
20:34:00 <sbalmos> otherwise a "blocking read" by a driver could be stupidly implemented by an idiot driver writer and actually busy-wait rather than actually really blocking
20:35:00 <geist> it's woken up at the bottom of the irq handler here:
20:35:00 <bslsk05> ​ lk/virtio-block.c at master · littlekernel/lk · GitHub
20:35:00 <sbalmos> ya
20:35:00 <sbalmos> it's funny how much I remember from college, conceptually, but it's reading it in code that clicks
20:36:00 <geist> it's a very simple driver since it doesn't allow queing. the blocking thread is holding a mutex across the operation which keeps only one thread in there
20:36:00 <geist> yah figured that might help
20:36:00 <geist> if it was more of a queued/multi io thing then the driver needs to build up some notion of pending transactions, and probably put a wait queue (event_t) in each of those, so the individual thread can wait on an individual transaction
20:36:00 <sbalmos> at the very least I was reading Redox source and already tilting my head at some stuff they do in there, either seemed left-over or really... not right
20:37:00 <geist> and then the irq handler would have to disambiguate which transaction the irq is completing and wake up the appropriate thread, etc
20:37:00 <sbalmos> yup
20:37:00 <geist> yah i glanced a bit at the redox stuff. i'm mostly chalking it up to not knowing rust that well, but i kinda get the impression it's written by folks that haven't done a lot of osdev
20:37:00 <geist> but i may just be not grokking rust
20:38:00 <sbalmos> nah it's not that. I don't know much rust either. But I tend to pick up on new languages, etc /very/ quickly once I actively start using them. And even then I've quickly gotten the sense of a lot of their code organization, you get that instinctual feeling things aren't right
20:42:00 <geist> rust may tend to force you down a particularly unoptimal path for this sort of thing, though
20:42:00 <geist> it always seems like the ownership model would work against you for a lot of these core 'toss this on a list and get to it from some other context' style stuff that tends to be in the deep of kernels
20:43:00 <sbalmos> dunno yet, honestly
20:44:00 <heat> sbalmos, usually the busy-wait drivers are the best ones ;)
20:44:00 <sbalmos> heh
20:44:00 <heat> as in, actively tuned and feature complete
20:44:00 <sbalmos> WTF did my CPU jet engine just take off? I was just trying to read a file!
20:45:00 <heat> intel mac moment
20:46:00 <heat> I introduce to you: RWF_HIPRI (man 2 preadv2)
20:46:00 <sbalmos> geist: took me a long while to find the entrypoint from gigaboot was actually top/ . Kept looking in all kinds of other places.
20:46:00 <heat> kernel block device polling!
20:47:00 <geist> ah well, entry to the kernel you mean?
20:47:00 <sbalmos> YUP
20:47:00 <sbalmos> gah, sorry
20:47:00 <geist> it's not entirely true, the entry is actually in arch/<arch>/start.S
20:47:00 <geist> it then eventually calls kmain()
20:47:00 <sbalmos> well yeah, I was there first
20:47:00 <geist> top/ is basically just the first part of the C code
20:48:00 <sbalmos> right, just on my neverending quest to trace-read the process
20:49:00 <sbalmos> bad enough CLion doesn't set up header search paths without a CMakeLists file, so I can't ctrl-click the header file includes :D
20:50:00 <heat> doesnt it use compile_commands.json?
20:50:00 <geist> sbalmos: you'll also note that the structure is basically the same as LK, that part hasn't really changed much
20:50:00 <geist> you'll see a lot of shared DNA there
20:50:00 <sbalmos> ya
20:51:00 <sbalmos> heat: /supposedly/ it should. but I have yet to get the project to recognize it on opening.
20:53:00 <sbalmos> hang on. this might be a difference in how IDEA/CLion, a few vers back, changed their open structure. It didn't recognize if I opened from the fuchsia dir, but is now asking if I want to treat the file as a project if I tried to open compile_commands.json directly
20:55:00 <geist> yah the compile_commands works pretty good, tough it's the whole shebang, including non kernel stuff
20:56:00 <geist> i have also been running a ctags over the whole thing which mostly works, though there are some kernel headers and whatout outside of the kernel dir
20:56:00 <sbalmos> I think I'm going to have to blow away all the previously generated .idea dirs. It's still not recognizing any headers
20:56:00 <geist> heads up: i think there's some deconstruction of the zircon dir that's about to happen, so stuff will move around soon
20:57:00 <geist> the incessant need to move things around in the source repo is a constant among the project, but i think it'll end up getting move to src/zircon/kernel or something, but some of the other bits in zircon/ are going elsewhere
20:59:00 <sbalmos> <Bones> "I know engineers, they love to change things..."
21:01:00 <heat> jeez, again? :/
21:02:00 <heat> clangd works fine but for a lot of files it needs some arguments to not blow up your machine
21:02:00 <sbalmos> good thing I don't really need my home desktop here for another 20 minutes while it chews through the indexing. ;)
21:03:00 <sbalmos> bah, stupid WSL
21:04:00 <psykose> heat: what arguments? :)
21:06:00 <heat> --background-indexing=false?
21:06:00 <heat> --background-index even
21:06:00 <heat> so, --background-index=false
21:06:00 <psykose> thanks!
21:06:00 <heat> although after re-reading clangd docs this doesn't seem that great of an idea
21:07:00 <heat> i usually just take the hit upfront
21:08:00 <sbalmos> ooof, stupid lack of symlink following in \\wsl$ paths
21:53:00 <liz> feeling very silly... spent a lot of time prodding my machine code to diagnose a PIC issue, only to realise i forgot to add an sti instruction in protected mode
22:00:00 <geist> oh eep
22:00:00 <geist> yeah that'll do it
22:01:00 <geist> though that's better than the other, having sti enabled when you're not ready for it. that's harder to debug
22:09:00 <sbalmos> geist: unsurprisingly I'm finding reading lk a lot more straightforward than zircon. probably just a sheer size thing.
22:09:00 <geist> yeah the zircon stuff has gotten much larger, though the structure is somewhat the same
22:10:00 <sbalmos> it is, more or less. so lk doesn't have any IPC stuff by what I can tell, right?
22:13:00 <clever> j`ey: not sure, ive not used it here
22:16:00 <j`ey> clever: got it working in the end, was an oopsie on my side
22:19:00 <geist> not too much, it does have a central 'port' mechanism, but the general idea is that only if it's really really cross-functionally useful does it get promoted to 'core' primitive
22:20:00 <geist> whereas various sub projects have built their own mechanisms for what they do
22:20:00 <geist> general overall idea being that LK is simplicity first
22:20:00 <sbalmos> yup, saw the port, and that's what I figured thinking it further
22:20:00 <geist> pretty much all of the core code is not fundamentally ipc based. more of a traditional blocking primitives and from that one builds queues/etc
22:21:00 <sbalmos> zircon probably builds the idea of a channel and everything else on top of a port and some mutexes, etc if it's to block. easily compose a message "mailbox" on top of that
22:21:00 <sbalmos> yup
22:21:00 <clever> j`ey: what was it?
22:21:00 <geist> precisely. port i dont think survived, but for the msot part mutex/event/wait queue/semaphores are still there, just converted to C++ and beefed up a bit
22:21:00 <sbalmos> oh hell it's almost 6:30 already. haven't even thought of dinner.
22:21:00 <geist> and all the higher level zircon code is built on top of it. LK is very much still there as the core to the whole thing, it's just been converted to C++
22:22:00 <geist> and certain scaling decisions have been made that involve rebuilding some things
22:22:00 <geist> (ie, the scheduler)
22:22:00 <sbalmos> well it's basically the same as how Darwin is really Mach at the original core, etc
22:22:00 <geist> yah, and over time they diverge but the DNA is still there
22:22:00 <j`ey> clever: I was printing a small amount of characters before hanging. I had a 'sleep 1 ; screen /dev/pts/N' loop in another terminal.. and the printing was so quick it had already always output stuff during the time it was sleeping
22:23:00 <clever> j`ey: ah, ive seen basically the same problem with MCU's emulating a usb tty
22:24:00 <clever> i think if you use -S to start qemu, it will create the tty, but halt the cpu
22:24:00 <clever> then you can resume it at a time of your choosing
22:24:00 <j`ey> clever: via the monitor I suppose?
22:24:00 <clever> yeah
22:24:00 <sbalmos> geist: funny (not really) how this is easier to wade through than Minix or others, when you kinda know what you're looking for and know what it's supposed to look like on paper, but not fully in code.
22:25:00 <clever> the monitor should also let you query what tty the serial landed on
22:25:00 <clever> and you can rig the monitor into a unix socket if you want to automate it all
22:25:00 <geist> sbalmos: that's been generally my strategy. i need to write many more docs for LK, but i'm so bad a it
22:25:00 <geist> zircon, i'd hope it's still easy, but frankly the code we're writing is not really designed to be easy to read, somewhat to my chagrin
22:26:00 <geist> i try, but it's a non-goal of the project, alas
22:26:00 <sbalmos> yeah :/
22:26:00 <sbalmos> it's turned from research/academic keep-it-studyable to commercial
22:26:00 <j`ey> thats why LK must live :D
22:26:00 <geist> yah, it's sort of the inevitability of it, alas
22:26:00 <geist> i *do* encourage folks to write docs for LK if your'e bored. there's a wiki next to it
22:27:00 <geist> and i haven't figured out precisely what i want to do re:wiki vs .md files, but all else held equal probably starting with the wiki is not a bad idea
22:27:00 <geist> can at least flatten some of that out
22:27:00 <sbalmos> I mean the Fuchsia dev docs do a great job on their own. But not so much from a "here's how things map in the directory structure / function-name level" past the syscall function names
22:27:00 <clever> j`ey:
22:27:00 <bslsk05> ​ nixpkgs/ at master · NixOS/nixpkgs · GitHub
22:27:00 <clever> j`ey: this will run qemu with -monitor unix:/path/to/socket
22:28:00 <geist> sbalmos: yeah agreed. and worse we keep rearranging things. for better or worse google has no fear constantly reformatting/refactoring/moving. i think that's part of the DNA of the company
22:28:00 <sbalmos> and it's taken me a while to learn to properly spell Fuchsia. :P
22:28:00 <sbalmos> ayup
22:28:00 <geist> incessantly redo things. i think it does actually work in the long run, but it doesn't make it easy to find thins
22:28:00 <j`ey> clever: cool, maybe unix socket is better than guessing the pts will be N because I have N-1 terminals open :P
22:28:00 <geist> i fought it for a whiel, but really it's just The Way.
22:29:00 <geist> also git makes it at least a lot easier to deal with than older SCMs
22:29:00 <sbalmos> geist: there's constantly stuff in FIDL I still can't find where it's defined
22:29:00 <clever> j`ey: one sec
22:29:00 <geist> you should see the internal mailing lists that are constantly 'X is being replaced by Y'
22:29:00 <sbalmos> heh
22:29:00 <geist> oh oops, i just let my machine OOM building clang
22:30:00 <geist> wasn't paying attention while typing here :)
22:30:00 <geist> 64GB and just blew through 32GB of swap in a few seconds
22:30:00 <j`ey> JOB_POOL_LINK, use it!
22:30:00 <geist> and now it's totally frozen. j`ey oh? how does one?
22:30:00 <sbalmos> heheheheh
22:30:00 <geist> -DJOB...?
22:30:00 <j`ey> yeah
22:30:00 <geist> will give it a go when i get back. gotta run to the store
22:31:00 <j`ey>
22:31:00 <bslsk05> ​ JOB_POOL_LINK — CMake 3.24.0-rc1 Documentation
22:31:00 <sbalmos> geist: ultimately THANK YOU
22:31:00 <clever> (qemu) qom-get /chardevs/serial0 type
22:31:00 <clever> "chardev-pty"
22:31:00 <clever> j`ey: i assume that soemwhere in here, is the pty name it randomly allocated
22:31:00 <geist> sbalmos: oh really? thanks! it actually really does keep me going to find that someone finds this stuff helpful
22:32:00 <geist> hmm, i always feel a little dangerous turning a computer off that's stuck in OOM hell
22:32:00 <sbalmos> do it!
22:32:00 <geist> but i gotta
22:32:00 <sbalmos> fsck solves world (memory) hunger
22:32:00 <j`ey> clever: probably, for now I can just hardcode it
22:32:00 <clever> yep, found it
22:32:00 <clever> (qemu) info chardev
22:32:00 <clever> serial0: filename=pty:/dev/pts/24
22:33:00 <j`ey> ty, added to my notes
22:33:00 <clever> so, you can either route the serial to a unix socket
22:33:00 <clever> or you can route monitor to a unix socket, and query which pty it wound up on, and pause/resume the machine when your ready
22:35:00 <klange> and for meatbag use, the latter prints it on startup
22:36:00 <gog> hi, am meatbag
22:36:00 <sbalmos> multipass?
22:36:00 <gog> MUL-TI-PASS
22:37:00 <klange> that's "meat popcicle".
22:37:00 <gog> there's a user that kicks around libera named azizLIGHT
22:37:00 <sbalmos> lol
22:38:00 <klange> Fifth Element is my all-time favorite live action film.
22:38:00 <gog> i love it, it's a solid vehicle for bruce willis and milla jovovich
22:38:00 <gog> just a fund mindless film
22:38:00 <gog> fun
22:39:00 <gog> sometimes i say "chickan--good!" when i have chicken :p
22:40:00 <zid`> cheeken
22:40:00 <zid`> goed
22:41:00 <sbalmos> I may have to eventually name my userspace critical-server watchdog process Mondoshawan
22:42:00 <klange> I live by the words of Jean-Baptiste Emanuel Zorg: If you want something done, do it yourself.
22:43:00 <sbalmos> klange: ultimately, if it doesn't work out, just press the little red button
22:48:00 <clever>
22:48:00 <bslsk05> ​'Silicon Photonics: The Next Silicon Revolution?' by Asianometry (00:15:45)
23:27:00 * geist mentions Everything Everywhere all at Once again. Fantastic movie
23:27:00 <j`ey> weird and fantastic
23:28:00 <mjg_> hm
23:28:00 <geist> I watched a bunch of making of, and am also pleasantly surprised to see it was pretty cheap to make and they were very scrappy with mostly practical effects
23:28:00 <geist> Sort of an anti-Marvell movie in terms of sci if and action
23:28:00 <mjg_> :))
23:28:00 <mjg_> in that case adding to my watchlsit
23:28:00 <j`ey> but still multiverse :p
23:29:00 <mjg_> which part of "everything everywhere all at once" you missed
23:29:00 <mjg_> :>
23:29:00 <geist> But still multiverse yeah. The creators said they were a little bummed that multiverse stuff got popular recently, because they’ve been basically working on it for like 10 years, but so it goes
23:29:00 <geist> OTOH maybe it primes audiences a bit to deal with the multiverse stuff in general.
23:35:00 <klys> one of a select few movies i did see
23:41:00 <geist> Yah i think it was the first one I’ve seen in a theater since the start of the pandemic
23:44:00 <zid`> lmk when it's on iptorrents
23:45:00 <moon-child> iptorrents? Isn't that a really trashy torrent tracker?
23:45:00 <zid`> not trashy in the least
23:46:00 <geist> Honestly this is such a good movie and indie enough that they deserve your money
23:47:00 <zid`> I don't have any money
23:47:00 <geist> Fine, but just sayin.
23:47:00 <zid`> all I can do is watch it then recommend to others to buy it
23:49:00 <zid`> or not, depending :p
23:49:00 <zid`> like, all my friends have seen primer because I wouldn't shut up about it
23:52:00 <geist> Indeed, thats one i didn’t shut up about either for a few years
23:52:00 <geist> Now that I’ve forgotten enough of it i should watch it again
23:53:00 <zid`> TIL qemu supports memory mapped shm between host and guest
23:53:00 <zid`> -object memory-backed-file,size=size
23:54:00 <geist> Yup. You can also file back the entire physical address space that way
23:54:00 <geist> One way to pre-fill it with random data
23:54:00 <geist> And if you use a COW file system or whatnot you can easily track deltas
23:55:00 <zid`> I should use -memory-backend or whatever to make that my vga memory
23:55:00 <zid`> and make my host machine repaint the background image as a gif or something
23:55:00 <geist> I have no idea what the performance impact of actually backing it to disk would be though, seems like Linux would be fairly furiously writing it back to try to get modified state to zero
23:56:00 <geist> But backing it to tmpfs or whatnot would be a way to get basically anonymous memorybacking it, but be able to examine the contents post-facto or whatnot
23:56:00 <geist> I thought i had read that some VM hosting solutions did that for some benefit