<bslsk05>
fuchsia.googlesource.com: zircon/kernel/arch/arm64/thread.cc - fuchsia - Git at Google
<heat>
i guess a release store will be some sort of dmb st vs dsb?
<geist>
on arm there's explicitly a `clrex` instruction
<geist>
on riscv i think it says to do an extraneous store to an unrelated cache line
<geist>
i haven't done it yet on riscv, i have a todo to do that
<geist>
i'll probably just write to a word in the percpu structure
<heat>
btw i think you could do even without locks on x86 given iret is serializing?
<heat>
right?
MiningMarsh has quit [Ping timeout: 245 seconds]
m3a has quit [Ping timeout: 246 seconds]
heat has quit [Quit: Client closed]
vdamewood has joined #osdev
SGautam has joined #osdev
Maja has quit [Remote host closed the connection]
<vdamewood>
I think I want to put this into my kernel's source code: khang: jmp khang
<dh`>
geist: iirc the store to bust ll/sc is only needed if you have a kernel so simpleminded that it manages to be able to interfere with a pending ll/sc without taking any of its own locks
<dh`>
which is basically not a thing, so there's no reason to bother putting it in
vinc has joined #osdev
deflated8837 has joined #osdev
PapaFrog has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
m3a has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
SGautam has quit [Quit: Connection closed for inactivity]
PapaFrog has joined #osdev
PapaFrog has quit [Read error: Connection reset by peer]
LostFrog has joined #osdev
LostFrog has quit [Read error: Connection reset by peer]
vinc has quit [Read error: Connection reset by peer]
PapaFrog has joined #osdev
PapaFrog has quit [Read error: Connection reset by peer]
LostFrog has joined #osdev
GeDaMo has joined #osdev
m3a has quit [Ping timeout: 246 seconds]
<geist>
dh`: well, sure. you have to context switch between two things doing a ll/sc without any intervening ll/sc
<geist>
but that depends on whether or not amoadds or whatnot also busts them, which iirc is not defined
<geist>
so it's one of those *hypothetically* sort of situations
<geist>
but yes it's highly improbable
[itchyjunk] has quit [Read error: Connection reset by peer]
<clever>
geist: i got side-tracked, now that ext4 and usb 90% work, trying to play bad-apple now, lol
<geist>
hah was just playing bad apple on my commander x16
<clever>
one frame per .tga file!
<clever>
then i just fs_open_file() every single file in one loop, that part seems cpu bound
<geist>
hah cute
<clever>
then i made a second loop, to just fs_read_file everything, and ignore the data
<clever>
thats IO bound, and hasnt finished, after 5+ minutes
<clever>
the ext2/4 driver doesnt merge requests
<clever>
so its doing a full round-trip to the usb, for every 4kb block
<clever>
but with ext4, you know ahead of time how big an extent is
<clever>
so it could be optimized more
<clever>
definitely too slow for realtime playback right now
<clever>
but its only 248mb of tga files, i could buffer them, then decode in realtime, maybe
<clever>
i also found your stats in bcache, and confirmed that going to 1024 blocks harms performance
<geist>
mmhmm. nothing really caps off a saturday like someone complaining on IRC about some code you wrote like 15 years ago
<clever>
not complaining
<clever>
just off the top of my head, the cpu bottleneck in fs_open_file() is probably because i'm ignoring the ext4 dir hash tables
<clever>
thats all my fault, because your code was ext2 only
<clever>
thru the bcache stats, i found that at size=64, it had more misses then size=128, so it evicted things it needed
<clever>
beyond 128, the miss rate never changed, and it only got slower with more size
<clever>
so i was just increasing the size too much
<geist>
that's probably it not having a proper hash table or something
<clever>
yeah
<clever>
both the ext and bcache are using linear searches
<clever>
bcache records how many elements it compared against in the stats, so you can tell when thats becoming an issue
<geist>
yup, just needs a hash table to speed that up
<clever>
ext4 hides a hash table inside "deleted" file entries, but i havent implemented the hash algo
<clever>
but, how often is bcache going to even be used on such a large cache?
<clever>
i might actually flip things the other direction, use 2 bcache instances
<clever>
one for metadata, one for data
<clever>
then reading large files wont trash your metadata hitrate
<clever>
the data cache can be small, if your reading the same file twice, thats your fault
<clever>
but the metadata cache can be larger, since it would massively complicate the FS to cache every bit of metadata
<clever>
now i feel like writing `top` or `perf top` for LK, all `threadload` says is 99% cpu
<clever>
reading thread.c, i think a quantum is 10ms, and a thread gets 5 every time it runs out
<clever>
and if it has ran out, it goes to the end of the run-queue
<clever>
but nothing else about tracking per-thread usage
<clever>
] read all files in 2020881732 uSec
<clever>
ah, it finished
<geist>
threadstats
<clever>
oh, nice, not sure how i missed that one
<clever>
ah, but its not per-thread i think
<geist>
yes it is
<clever>
checking src...
<clever>
and a distraction has come up, i'll read more later
<clever>
geist: in the source, that is per-core, not per-thread
<clever>
but will still be a good example of where to insert the counters
<geist>
old source
<clever>
ahhh, i'll have to rebase
<clever>
rebased with zero conflicts! and now i see dump_threads_stats()!
<geist>
not really top but it might get you what you want
<clever>
but `perf top` is something your unlikely to have, would need symbols and all that jazz
<clever>
and arch specific support for stack unwinding
<clever>
so ive still got some fun i can do
<clever>
platform/bcm28xx/platform.c:164:15: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
<clever>
somehow, casting an uint32_t to a void*, is suddenly invalid, when it was valid before the rebase
<geist>
probably some new warnings
Burgundy has joined #osdev
<clever>
platform/bcm28xx/platform.c:131: Error: no such instruction: `version %esi'
<clever>
geist: oh!, its because the cross-compiler stuff is broken
<clever>
its using the wrong compiler, so void* is the wrong size
* geist
nods
<clever>
yep, NOECHO= reveals its using plain gcc, the host x86-64 gcc!
* geist
nods
<clever>
TOOLCHAIN_PREFIX = vc4-elf-
<clever>
but it did print this during the build
<clever>
maybe its respecting $CC suddenly?
<clever>
yep!
<geist>
it is
<clever>
lk/lib/libc/atof.c:80: undefined reference to `__muldf3'
<clever>
and something with libgcc.a has changed?
<geist>
possibly whether or not it uses float or not
<geist>
sdepends on how old your branch was before
<clever>
float worked before the rebase, will need to investigate more
<geist>
yes i changed some way float was done a while back
<clever>
ah
<geist>
added some new nofloat modules, etc. so i think your arch code needs to be moved up to date
<clever>
ah, to tag it as having hw 32bit float
<geist>
actually need to revisit it since it's not really ideal
<geist>
but i forget the details and it's 1am on a saturday
<clever>
i'll look at what arm32 does
<clever>
go sleep!
<geist>
well, no, i dont want to sleep i just dont want to tech support this right now
<geist>
look throught he commits an dyou'll probably find what i did
<clever>
yeah
<geist>
the float stuff was done well over a year ago, so you have gotten fairly out of date
<clever>
i see a new `MODULE_OPTIONS := float`
<clever>
make/module.mk looks to have some logic that i should read closer...
<clever>
ah, i see, that new flat allows the compiler to use hw floats
<clever>
so you can make things interrupt safe, by doing softfloat elsewhere
<clever>
00000000 g F .text 000004a8 .hidden __muldf3
<clever>
i do see the symbol within my libgcc.a
<clever>
so i just need a -lgcc i think
<geist>
you shoul dhave always had that
<clever>
never needed it before, it might have been in one of your files
<sham1>
You need it always when compiling with gcc
<clever>
/home/clever/apps/rpi/lk-overlay/lk/lib/libc/eabi.c:35: multiple definition of `__dso_handle'
<clever>
/nix/store/cwpy4q0qvdwdif1zfwnfg5gi50c6j9w8-vc4-elf-stage-final-gcc-debug-6.5.0/lib/gcc/vc4-elf/6.2.1/crtbegin.o:(.data+0x4): first defined here
<clever>
i think the normal baremetal flags like nostdlib are missing, and its linking new things
<geist>
dont link that
<geist>
right
<clever>
but i'm not sure why, git logs say it wasnt removed
<clever>
will need to dig more after the distractions clear
<geist>
resync your arch rules.mk. it probably got out of date via something changing
<clever>
yeah
<clever>
ive also noticed, linker gc breaks lib/fs
<clever>
there is no KEEP on that section
<geist>
feel free to actually roll changes back into mainline
<clever>
yeah, i also need to finish my ext4 stuff and upstream that too
<clever>
ah, arch/arm/rules.mk has some libgcc.a logic!
<clever>
it seems it now wants an absolute path to libgcc.a
<geist>
correct
<geist>
not now, always has
<clever>
ah
<clever>
checked my git history, i was last on a commit from 2022-09-25
<clever>
baca46e13344bec7adffcdc4e583288a86696b9a
<clever>
now i can just pull up the diff, and read that closer
<geist>
atof() was added in the interim, so it now needs libgcc that you never were providing before
<clever>
i already had an strtof somewhere, and just had to add it to a .h file
<clever>
looks like they basically do the same thing, but strtof seems better
<clever>
ah wait a moment, its creating libc.mod.o, why is it even linking crtbegin then!?
<clever>
thats only for the final link
<clever>
(if at all)
<geist>
its not at all
<geist>
somethign is off in your arch
<geist>
and/or one of CC/LD/etc is being overridden
<geist>
but again i really dont want to provide tech support right now, can we put a pin in this?
<clever>
ah yeah
<clever>
i'm mostly just talking to myself, feel free to ignore me
<geist>
i cant.
<clever>
thats why i said to go to bed, you dont have to answer
<geist>
it's intense nerd sniping
<clever>
lol
<geist>
like if i know you're talking about it i cant *not* drop what i'm doing to look
<clever>
one last thing then, i had found a commented `LD := vc4-elf-gcc` in my arch file, uncommenting it broke libc.mod.o
<clever>
re-commenting went back to the previous issue
<clever>
something i'll need to investigate more
<geist>
that's why. it' susing gcc to link it (vs ld) ad that's bringing in ctrbegin/etc
<geist>
LK uses arch-ld to link explicitly
<clever>
yep, forcing the -ld version worked
<clever>
aha, link order again, -lgcc has to go after the usage, not before!
<clever>
and LIBGCC does that,so i just need to populate it, like arm
vinc has quit [Read error: Connection reset by peer]
<GreaseMonkey>
well, that was "fun", had screwy VGA output until i realised the CGA compat and Hercules compat flags in CRTC register 0x17 were supposed to be set to 1 to disable them
dennis95 has joined #osdev
vinc has joined #osdev
CaCode has joined #osdev
vinc has quit [Read error: Connection reset by peer]
zxrom has quit [Remote host closed the connection]
vinc has joined #osdev
vinc has quit [Read error: Connection reset by peer]
sortie has quit [Quit: Leaving]
netbsduser` has quit [Ping timeout: 246 seconds]
MiningMarsh has joined #osdev
<sham1>
hi
osdev-guest has joined #osdev
<osdev-guest>
Hi! Regarding RISC-V (using QEMU), is it better to use the linker script, which involves adding a heap region, or should I solely rely on the device tree for memory allocation?
gog has joined #osdev
vinc has joined #osdev
<zid>
better for what?
<gog>
meow
<zid>
henlo
<osdev-guest>
Better for a general purpose operating system.
<osdev-guest>
The linker script approach is easier but comes with the problem of having a fixed amount of memory.
<zid>
again, depends what you mean by better, just decide what you want
<zid>
do you want to write it later, or now
<zid>
99% of the time these projects never ever get far enough that 'this will be useful in future' ever actually comes to pass
<zid>
I wouldn't write anything that wasn't immediately useful
<osdev-guest>
This is a fairly educational project
<osdev-guest>
So maybe the linker approach is more appropriate in this case
<osdev-guest>
But I was asking to know the general opinion about this, since some projects use the device tree
<Ermine>
gog`: may I pet you
vinc has quit [Read error: Connection reset by peer]
<bslsk05>
'i live in a low income housing environment' by Physic snail (00:00:32)
Cindy is now known as bnchs
<zid>
mcrod did you dark more soul
<heat>
btw mcrod DLC?
<heat>
u doing it this run or what
simpl_e has quit [Remote host closed the connection]
Harriet has left #osdev [not now]
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
xenos1984 has quit [Ping timeout: 245 seconds]
xenos1984 has joined #osdev
<mcrod>
i'll do it this run
<mcrod>
zid: yes
<mcrod>
but I _really_ need humanity
<zid>
what for
xenos1984 has quit [Ping timeout: 246 seconds]
<heat_>
summon solaris for the nito fight of course
<heat_>
and then summon solaire
bnchs is now known as Cindy
zxrom has joined #osdev
<mcrod>
no
<mcrod>
i just need more than 5 estus
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
xenos1984 has joined #osdev
antranigv has joined #osdev
<heat_>
mcrod, have you tried farming the baby skellies?
<heat_>
they're your best bet
<heat_>
careful tho, they're kinda dangerous
wblue has joined #osdev
<mcrod>
no but I should try to farm them
<mcrod>
also probably covetous gold
sortie has joined #osdev
Harriet has joined #osdev
CaCode has joined #osdev
<heat_>
mjg, is freebsd + kasan zone allocation scalable?
<heat_>
i assume not but i wanna make sure
<heat_>
i'm quarantine'ing memory instead of sticking it on a pcpu free list and that takes a toll on my slab allocation
<heat_>
i unfucked the slab allocation routines to drop the lock and that just... moved the contention point elsewhere (vmalloc does not scale)
<heat_>
but i assume that at any memory allocation point i'll want to properly quarentine things
<mjg>
i don't know, i would guess no
<mjg>
whacking one bottleneck only to immediately run into another is the multicore life of a legacy codebase
<mjg>
you are fucking up to be in this spote mate
<mjg>
:X
<heat_>
well, no
<Ermine>
freebsd's memory management is legacy code?
<heat_>
it's just hard to be super scalable while maintaining the KASAN properties you want
<heat_>
(coherency, safety)
<mjg>
you said your vmalloc does not scale?
<mjg>
i assumed that's without kasan
<mjg>
if memory serves you have top kek problems
<heat_>
yes, but even if it did, i wouldn't want it to
<heat_>
like, supposedly you want to put memory away for as long as possible
<heat_>
and i don't see many ways of doing that without fucking scalability over
<heat_>
if i switched things over to the page allocator i'd just switch the contention point to a page allocator zone
<sortie>
heat_
<heat_>
hi sortie
<Ermine>
hey
<sortie>
How're you?
<heat_>
im fine thanks
<heat_>
my stomach is way less fucked but now the heat wave is hitting and OH GOD THE CATHOLICS
<sortie>
hi fine thanks I'm sortie
<heat_>
how are you?
<sortie>
I just got back home and did a festival on my birthday yesterday
<Ermine>
We also have a lot of heat outside
<Ermine>
happy birthday sortie!
<sortie>
Yayyy thanks Ermine :D
<heat_>
happy bday sortie!
<sortie>
heat_, one of my fav bands wished me a happy bday and dedicated a song to me :D
<Ermine>
That's sweet!
<sortie>
Also hung out with another fav band that also wished me a happy bday and took a taxi homewards with the guitarist
<sortie>
Fun :D
<Ermine>
Super fun
<sortie>
I'm feeling like doing some osdev
<sortie>
It's time to patch GRUB
<heat_>
ohno
<heat_>
you're going from poggers to AHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
<sortie>
heat_: hmm=
<sortie>
?
<sortie>
also beself
<Ermine>
I'm feeling like doing osdev too
<Ermine>
unfortunately it's late
<sortie>
I did all of my best osdev at 2 AM
goliath has joined #osdev
<Ermine>
I get enlighted at 4 AM
<netbsduser`>
Ermine: by god, you're right, already 8 o clock
<netbsduser`>
how in stinking crikey did it get to this time
<mjg>
heat_: you don't non-kasan vmalloc to scale?
<Ermine>
But if I go to bed late, my stomach goes crazy the next day
vinc has joined #osdev
<heat_>
sortie, patching GRUB is pain
<heat_>
in fact most linux distros are stuck in endless GRUB patching pain
<Ermine>
Writing new bootloader is relatively poggers
<mjg>
lmao
<mjg>
this is why gentoo is the way to go
<mjg>
you are too busy compiling in a loop to reboot
<sortie>
heat_, ah it's fairly contained to configuration file stuff that is quite Sortix specific
<mjg>
does mainline sortix do multicore now?
<mjg>
how about some dragracing vs onyx
<mjg>
:X
<heat_>
mjg, btw, no. my vmalloc is kinda sucky atm. falls to the traditional mmap allocation problem (O(N) allocation), plus no pcpu caching nor lazy tlb flushing, etc
<sortie>
mjg, just spin up two Sortix VMs :D
vinc has quit [Read error: Connection reset by peer]
<mjg>
sortie: that's the openbsd solution :d
<Ermine>
heat_: didn't you plan to implement rcu?
<heat_>
yes
<heat_>
Soon(tm)
<sortie>
mjg: Mostly concerned about various important release and usability aspects at the moment, like making networked upgrading working, improving the packaging formats, fixing release blockers, making it possible to do better upgrades
<mjg>
you seem user-experience focused
<mjg>
what kind of dev does that
<heat_>
lol i dont even have users
<heat_>
the fuck is that
<mjg>
^^ there you go
<sortie>
E.g. lots of distribution-level stuff that's really important and will lock my ability to change technical aspects incompatibly if I don't plan ahead
<mjg>
who gives a fuck you can even'ti nstlal onyx, when it scales better?
<mjg>
can't*
<mjg>
you can install openbsd, but it scales worse
<mjg>
so i'm not using it
<heat_>
amen brotha
<heat_>
there's no more uncomfortable question than "how do I install onyx?"
<mjg>
i note again that obsd probably retains their totally fucked rw locks
<sortie>
mjg, yeah one can install openbsd, but have you seen the upgrade process?
<heat_>
the answer is: you don't, use windows
<mjg>
and mutexes
<sortie>
mjg: Serious rant here incoming
<mjg>
oh?
<heat_>
OPENBSD RANT TIME
<mjg>
wait, you mean upgrade to another version or just patching
<mjg>
bugs patching is supposedly easy, a 'la linux
<mjg>
you do magic-command upgrade or similar and bam
<mjg>
however, upgrading to another version is probably good old recompile by hand
<mjg>
and then follow a readme
<mjg>
to cleanstuff by hand
<Ermine>
Is EFI_FILE_PROTOCOL buffered?
<mjg>
sortie: waiting for the rant :]
<sortie>
https://www.openbsd.org/faq/upgrade72.html ← Okay so here's an example, not the worst upgrade this one looks kinda okay, but see the section like "Files to remove"
<bslsk05>
www.openbsd.org: OpenBSD Upgrade Guide: 7.1 to 7.2
<heat_>
Ermine, no
<mjg>
ye, that's how they were doing it for years man
<mjg>
i'm very well aware
<mjg>
:]
heat_ has quit [Remote host closed the connection]
<mjg>
21:16 < mjg> and then follow a readme
<mjg>
21:16 < mjg> to cleanstuff by hand
Lian has joined #osdev
<mjg>
pretty lame, no?
<sortie>
switch(4) and switchd(8) have been removed from the base system.
<sortie>
To cleanup the user, group, and associated files execute the following commands:
<mjg>
you would think, if one is to execute this shite literally, why not add it to a fucking script or something
<mjg>
and maybe ask the user if they want to do the action
<sortie>
I mean they usually have a bunch of "oh, but special case, you also gotta do X" follow up steps to upgrades
<mjg>
would be too user friendly
<mjg>
interestingly, obsd users boast about the supposedly trivial insallation process
<sortie>
Right an important context is that OpenBSD did inspire the Sortix install and upgrade process
<mjg>
"hit enter a few times, done"
<mjg>
wait what :d
<mjg>
sorts
<sortie>
But that upgrade process made me think "yeah I can totally do much better" (also with regards to installation btw)
<mjg>
for me the quintessential install bit is they ask if i'm gonnna use X
<mjg>
i say no
<mjg>
then they propose a disk layout which has a /usr/X11 partition
<mjg>
:d
<mjg>
make sure to retain this step
<sortie>
The Sortix upgrade backend is quite powerful and solves all of these problems automatically and transparently
<Ermine>
they still put x11 stuff in a separate directory???
<zid>
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff865248686, pid=28072, tid=29296
<zid>
java ur dum
heat has joined #osdev
<Ermine>
Ah, so I need to implement my own buffers around EFI_FILE_PROTOCOL
<mjg>
here is a serious question sorts
<mjg>
all this sounds like shit work one would do for a real project
<mjg>
why even bother
<mjg>
do you actually enjoy this?
<mcrod>
do we even enjoy anything
<sortie>
sysupgrade/sysmerge both use the /tix/manifest/* files for each port which contains a list of what files it contains, and then it compares the contents of the source and target filesystem, and it automatically removes all the files that no longer exists, even handling files that have moved to another port
<heat>
here is a serious question heat
<heat>
all this sounds like shit work one would do for a real project
<heat>
why even bother
<zid>
GC crashed
<heat>
do you actually enjoy this?
<Ermine>
You do
<Ermine>
If you didn't enjoy this you wouldn't do this, right?
<sortie>
sysupgrade/sysmerge also have a one-time upgrade hook mechanism, if the target system doesn't have a /share/sysmerge/foo marker file, then the upgrader runs a one time upgrade step that does things like convert configuration files to new formats and other rare migrations
<heat>
i want mjg to understand it's a very stupid question
<heat>
we do this for the love of the game
<sortie>
sysupgrade/sysmerge also does things like update the initrd, reinstall the bootloader, all that stuff. It's all handled automatically. It also uninstalls ports that no longer exists.
<mjg>
heat: i don't know anyone who likes installer work
<heat>
sortie likes distro work
<heat>
have you seen his ports collection?
<heat>
all his *utilities*
<mjg>
so you might have missed this bit
<sortie>
mjg, basically all that bullshit from those upgrade guides, it's all automated and easy.
<mjg>
21:22 < mjg> do you actually enjoy this?
<mjg>
sortie: i believe you, but why did you do it :]
<sortie>
It's osdev, I do what I do :)
<heat>
[20:23:30] <Ermine> If you didn't enjoy this you wouldn't do this, right?
<mjg>
it's not how people work Ermine
<sortie>
mjg, but seriously I did try every single Unix I could get my hand on and tried upgrading them, and honestly sooo many of them had shitty experiences
<mjg>
what's your opinion on fbsd
<mjg>
:)
<heat>
it absolutely is
<mjg>
and net
<Ermine>
Also, apparently there are no readv/writev analogues in EFI_FILE_PROTOCOL
<heat>
these are hobby projects
<sortie>
DragonFlyBSD didn't even have an upgrade mechanism besides rebuilding from source
<heat>
no one's paid for this
<mjg>
sortie: netbsd has one?
<sortie>
mjg, been a few too many years since fbsd and nbsd so won't comment on them :)
<mjg>
i though they also build
<mjg>
aight
<heat>
Ermine: what are you doing/do you need any help?
<sortie>
mjg, but honestly you know what inspires me to osdev? Whenever existing systems suck. It makes me feel "I can do better"
<sortie>
So much Linux and BSD bullshit has inspired me for Sortix :)
<Lian>
i feel like i dont even want to do osdev, i really just want to do WM/DE dev but that doesnt sound as cool
<Lian>
X)
<sortie>
mjg, as for the whole "why bother if there's no users", well you gotta build it before they come
SGautam has joined #osdev
<Ermine>
heat: my plan for a prototype is to load a kernel from ESP and look for multiboot header
<sortie>
I made Sortix 1.0 installable and upgradeable (more or less, some parts were delayed to 1.1, when I need it) and I made the promise that one can install Sortix and easily upgrade it to newer versions, so you know it's a safe and supported installation
<sortie>
I'm definitely running around in circles around the other hobby osdev systems with how well I'm doing this
<Ermine>
So i need to make a buffer for lookup process to not suck
<mjg>
sortie: or you could fix the bullshit in the system
<mjg>
sortie: so you expect actual users one day?
<sham1>
Actual user might include sortie himself
<sortie>
mjg, and yeah, I enjoy a job well done. A lot of the work has been making the install + upgrade implementation simple and powerful with a solid implementation that has great usability
<sortie>
Well you know, I actually AM using this myself, big time. My websites run Sortix, I run an irc network on Sortix, even build Sortix on Sortix, even have a shared multiuser sortix server people can ssh into
<Lian>
does sortix come with xfree86 or xorg?
<Ermine>
Lian: it comes with display(1)
<sortie>
Lian, the latest nightlies come with display(1), my own little GUI
<Lian>
ooo fancy
DanDan has quit [Ping timeout: 245 seconds]
<sortie>
mjg, but yeah I am actually planning for real users here, Sortix has become a quite useful server system actually. It's easy to install a server with things like sshd, nginx, whatever custom daemons you got.
<mjg>
congrats mate
<mjg>
i don't think there are many systems which got anywhere near real-world usability
<heat>
Ermine: seeking around works
<sortie>
Also yeah I am not really motivated to fix Linux & BSD bullshit that much, lots of it comes from compatibility constraints that they have decided to have, that I don't have to have
<heat>
you could also just read it all to a big buffer
<heat>
that's ok
<mjg>
sortie: :D
<mjg>
fuckin' tell me about it
<mjg>
absolute nightmare on that front
<sortie>
Yeah making a clean system without bad constraints is a big part of what I enjoy about Sortix
simpl_e has joined #osdev
gorgonical has joined #osdev
<gorgonical>
Does anyone else think we should get hazard pay for working with bootloaders?
<gorgonical>
I lose so much time to just the bootloader and firmware stuff, and the real kernel stuff takes maybe 1/4 the total work time when I'm fiddling with bootloader/firmware stuff
<mjg>
sortie: but it still pretends to be unix?
<mjg>
my main gripe is the shit APIs
<mjg>
nothing can be done unless you reimplement everything yourself
<sortie>
mjg, usually the problem is a few APIs that made life difficult across the system, and often I am able to drop them
<sortie>
Things like putenv(3) is a problem because it leaks memory and it's unclear who owns it, so now setenv(3) and all the rest need to keep track of what variables are supposed to leak => complexity spreads because of one bad API
<heat>
the gang implements FORK
<sortie>
In Sortix, I've actively refused to implement a bunch of bad APIs, only providing the better versions that are usually widely available
<sortie>
In a few places I've just invented some better APIs myself
<sortie>
But generally I am actually happy enough with POSIX, just a few issues here and there that need to be improved
<sortie>
Meanwhile I actually strive to implement POSIX and the key system calls really well with various technical qualities
<mjg>
that is a manager statement
<mjg>
openbsd has multicore support with varying quality
<sortie>
I actually mean very specific things when I say that, there's a whole philosophy to how I do this stuff, mostly communicated it in chat, never wrote it all down together
<mjg>
well i admire your resolve
<mjg>
i'm a "get prototype working and ditch it" kind of guy
<mjg>
productizing a solution is pain
<mjg>
i mean all the error handling and idiot-proofing
<sortie>
The thing that matters is what real ports actually do, whether I can actually get away with being different & better, you know, pick your battles
<mjg>
you are either linux or it does not work
<mjg>
or it predates dotcom bubble crash
<sortie>
Truthfully ports are insatiable
<sortie>
If you do all the stuff they want, it'll suck massively and might even be internally contradictory, or you must be Linux
<gog>
hi
<sortie>
(and even Linux is full of contradictions that distros have patched)
<gog>
i'm bootloading
<sortie>
But yeah, in Sortix I have the philosophy of patching port bullshit away (and upstreaming the patches) so they behave properly with the key qualities I require as a baseline
<zid>
oh no
<mjg>
"interestingly" existing ports trees like bsd ones or linux are full of absolute garbage
<zid>
sortie: sort of like #ifdef LINUX feature1(); else featurea(); #ifdef LINUX feature2(); else featureb(); and featurea and featureb aren't actually a useful configuration?
<zid>
I could totes see that happening
<gog>
#ifdef CAT pet();
<sortie>
Truthfully sometimes that's easier to patch than configure
<mjg>
aah ./configure
<gog>
autotools autotools autotools
<sortie>
I am fluent in configure
<mjg>
perhaps i should write a kernel comlpete enough to autounlink the file on execution
<sortie>
I know nothing about m4
<gorgonical>
maybe it's just me but honestly #ifdef PLAT_A feature() #endif makes me react violently
<gorgonical>
something about it is just wrong
<sortie>
But I can patch the fuck out of a configure script
<linkdd>
hello there, i seem to have missed something in my understanding of the toolchain i'm using. I have clang v17 (for its support of c++23). for reference, here is my compilation options: https://bpa.st/SHTQ as you can see, i do have the `-ffreestanding`. I also refer to https://en.cppreference.com/w/cpp/freestanding in order to determine what headers I can use in the freestanding environment. It specifically
<bslsk05>
bpa.st: View paste SHTQ
<bslsk05>
en.cppreference.com: Freestanding and hosted implementations - cppreference.com
<linkdd>
says that <atomic> is available since c++11. BUT, when I include that header, clang (v17) will include the following: https://bpa.st/NVEA however, the cstdlib header **should not** include stdlib.h in a freestanding environment.
<bslsk05>
bpa.st: View paste NVEA
<linkdd>
it seems that the __GLIBCXX_HOSTED is defined to 1 instead of 0
<linkdd>
any ideas? or should i ask on the clang channel (if there is one?)
<sortie>
This is a great place to ask about that, though I use gcc myself so I can't help with this question :)
<heat>
linkdd: c++ freestanding is very incomplete
<heat>
it's also buttfuck hard to get working correcly without hacks
<bslsk05>
wiki.osdev.org: Meaty Skeleton - OSDev Wiki
<sortie>
Building a cross gcc is a very well supported workflow in here that everyone knows about
<linkdd>
yeah but i was like "hey, let's make it harder and use clang which is already a cross compiler"
<linkdd>
thanks for the resources though
<sortie>
clang can totally also be used, though unclear if anyone documented all of it, and whether it works as well as the documented gcc workflow that you can follow all the way until you even compile gcc on your own os
<linkdd>
i'll look at it
<heat>
both workflows are subtly broken
<sortie>
"clang which is already a cross compiler" is a statement that is not quite true out of the box, you really need to still set it up properly
<heat>
cross-gcc will have broken libgcc's on most archs (non-i686)
<sortie>
Just using clang wrong is just as wrong as just using gcc
<heat>
clang will not even have them at all
<linkdd>
sortie: right
<netbsduser`>
clang being an inherent cross compiler is of limited avail if your target is not of it
<netbsduser`>
it has no x86_64-keyronex or m68k-keyronex targets so i would still have to built the thing
<sortie>
linkdd, the details here are incredibly important, if your compiler is not actually a true cross-compiler, then lots of stuff can break in subtle and surprising ways that will fuck you up
<heat>
netbsduser` even if it did you'd lack all the runtime libs
air has quit [Ping timeout: 258 seconds]
<sortie>
Yeah what netbsduser` said, clang and gcc can't know about your OS down the road, you need to teach them about your OS and build them
<bslsk05>
github.com: Onyx/kernel/lib/compiler-rt/builtins at master · heatd/Onyx · GitHub
<heat>
(which actually works pretty well with both clang and gcc)
<heat>
and accomodating all these differences is horrendous and time consuming and needs prior knowledge
<sortie>
Meaty Skeleton is really one of the best things I've done
<sortie>
Showing newcomers how to structure a new OS with a sysroot and proper cross compilation
heat42 has joined #osdev
heat42 is now known as heat69
<heat69>
yeah meaty skeleton is pretty nice
<heat69>
onyx still has some leftovers from that
<sortie>
And how to provide a libc and libk
<heat69>
oh it has .d support now
<heat69>
sweet
heat has quit [Ping timeout: 246 seconds]
<heat69>
"now"
<heat69>
2016-09-02 lmao
<linkdd>
adding --target=x86_64-pc-none-elf makes the compiler unable to locate the builtin headers, like cstdint, or cstddef
<heat69>
good
<heat69>
you don't have those
<heat69>
that's libc++ stuff you do not have
<heat69>
welcome to hell pal
<sortie>
Does <stdint.h> work?
<heat69>
i believe it should
<sortie>
gcc does provide that in the compiler itself when freestanding
<heat69>
if they provide that, that is. i don't remember if they do
<sortie>
stddef.h definitely
<sortie>
Varies from platform to platform whether stdint.h is provided by gcc or libc
<sortie>
In *-elf it's gcc
<linkdd>
yes it does
<sortie>
I don't trust those cfoo headers pretending to be <foo.h>
<linkdd>
but if cstdint is not available, that means stuff like atomic, initializer_list, etc... won't be available as well
<heat69>
the clang stdint.h, stddef.h, etc stuff is fully generic
heat has joined #osdev
<heat>
my connection not being a piece of crap challenge [IMPOSSIBLE]
<heat>
you can't use libc++ if you didn't build it for that arch
<heat>
which you didnt
<heat>
again, welcome to hell
<heat>
toolchains are great and horrific
<heat>
at some point you say screw it and do it all yourself
<heat>
honestly, the more standard the worse
<sortie>
heat, yeah sorry we went a technician to upgrade you to a professional Sortix network but you weren't available when we knocked
<linkdd>
so i just have to build libc++ for my target, and link to it, right? :P
dutch has quit [Ping timeout: 260 seconds]
heat69 has quit [Ping timeout: 246 seconds]
<sortie>
linkdd, 'just', note how cursed things can be if you want to link it into the kernel
<linkdd>
sortie: yes, "just" was sarcastic
<sortie>
linkdd, for instance, it may need to be built entirely differently with different compiler options
<heat>
linkdd: your target doesn't support libc++
<heat>
unless they have some barebones freestanding mode im not aware of
<sortie>
For instance on x86_64, -mno-red-zone is needed for the kernel since the CPU interrupts will trash your stack (unless you use the ability to switch stacks on interrupts)
<heat>
that may be the case, i havent worked with bare elf targets since forever
<linkdd>
what is the point of "freestanding c++" if you can't target a freestanding environment...
<heat>
its not, no one uses freestanding C++
<sortie>
I had the worst bugs because my libk/libgcc wasn't built -mno-red-zone and I linked it into the kernel
<heat>
or you take all your toolchain knowledge and cobble a bunch of shit hacks to make things work
<linkdd>
sortie: i have this compiler option already
<heat>
sortie: right, which is why most libgcc are subtly broken
<heat>
+ -mcmodel=kernel not being there
<sortie>
linkdd, neato, just saying that if you build compiler libraries for use in your kernel, you will need a dual build of the kernel versions and the userland versions
<heat>
and on other archs, fpu being enabled, etc etc (riscv doesnt even let you link)
<heat>
IMO either don't use anything compiler related, or ship your own compiler-rt
<heat>
the libgcc builtins part is pretty stable for each arch
<linkdd>
sortie: well, my kernel library is statically linked into the kernel (.a), and it is built with the same cxxflags. it's just that i wanted to rely on some of the features that should be available in freestanding (like <atomic> and <initializer_list>, or <utility> for std::move / std::forward, ...)
<linkdd>
but i guess i'll just have to write my own version of those headers
<linkdd>
"just"
<sortie>
Yeahhh
<heat>
you can't
<sortie>
You can probably import some code?
<heat>
<initializer_list> is compiler-specific
<sortie>
At least temporarily
<heat>
<type_traits> is compiler-specific
<netbsduser`>
i didn't used to rely on libgcc but now that i have an m68k port i do need it for 64-bit division and such
<linkdd>
heat: yeah i know, concepts as well. so i need to make some sacrifices
<netbsduser`>
and as for a lot of the C++ header files they have become freestanding in GCC 13 thanks to the efforts of veteran GCC hacker arsen
<linkdd>
no --target=x86_64-pc-none-elf or no <type_traits> / <concepts> / <initializer_list> ?
<heat>
you know <source_location>? believe it or not, very compiler specific
<heat>
linkdd: -elf will let you make less mistakes
<heat>
no one needs type_traits anyway
<linkdd>
-elf or -gnu, the problem is -none-
<heat>
no
<linkdd>
heat: i do, i have my own templated containers, and i use concepts and such fancy features
<heat>
that has nothing to do with anything
<heat>
-elf is a bare metal target so x86_64-pc-none-elf is (for clang) the only valid combination there
<Arsen>
i'm not sure veteran applies :P
<heat>
\o/
<linkdd>
heat: with -linux- it does find the c++ headers i want
<heat>
-linux-elf?
<linkdd>
complains about a missing features.h :)
<heat>
i have no idea how thats supposed to be parsed
<heat>
*shrug*
<heat>
ofc
<heat>
those headers are tailored towards glibc
<linkdd>
-linux-gnu is my host system
<linkdd>
so it would not make sense to just give it the same target triple
<Ermine>
Seems like my spare adapter is dying. wpa_supplicant floods logs with CTRL-EVENT-SIGNAL-CHANGE ... noise=9999 ...
<linkdd>
no, my trarget is x86_64-pc-none-elf, i need to build the toolchain for this target
<netbsduser`>
Arsen: give it time
<heat>
do consider if this is a battle you want to fight *right now*
<heat>
because fighting the toolchain(s) is a very extensive, hard battle
<linkdd>
i want <type_traits> and those compiler specific headers
<sortie>
I found a finn to plot with against the Torvalds regime
<heat>
i like the torvalds regime tho :(
<heat>
its nice and comfy
* Ermine
looks forward for his new wifi adapter
<sortie>
It's all socialism and freedom under the Torvalds regime until you accidentally upload a kernel binary and don't wanna share the sources then it's jail time
<Arsen>
heat: why with-newlib?
<heat>
sortie, true socialism!
<heat>
Arsen, --with-newlib makes libgcc go into no-libc mode
<Ermine>
sortie: companies upload module binaries without source
<bslsk05>
wiki.osdev.org: Hosted GCC Cross-Compiler - OSDev Wiki
<heat>
well, this is not a hosted libgcc
<Ermine>
I will never stop ranting about stock router firmwares sources
<heat>
that would depend on a libc
<sortie>
libgcc does need a few libc things like memcpy in principle
<heat>
libgcc_s.so also links against libc.so :)
<heat>
which doesn't help if libc links with libgcc
<sortie>
But libgcc.a doesn't actually need to link with libc
<heat>
also requires headers, etc
<sortie>
Headers are a non-problem
<heat>
so I build two toolchains
<sortie>
You can just install those
<sortie>
libgcc_s yeah is a future concern of mine, I'll figure it out when I do dynamic linking
<heat>
stage 1 is a nolibc minimal gcc build, which builds musl, stage2 builds against musl
<heat>
(stage2 includes clang too)
<heat>
this is more or less the LFS approach too
<sortie>
Ah, right, one thing I've done is to detach libstdc++ from gcc
<sortie>
So I don't need two stages
<heat>
stage 2 also includes libstdc++, libsanitizer
<sortie>
I can just build the gcc and libgcc using only headers
<sortie>
Then I can build libc
<sortie>
And finally libstdc++
<heat>
don't you get a slightly gimped libgcc in that case?
<sortie>
libstdc++ as a forced part of gcc is so wrong and unuseful when bootstraping things in the right now
<sortie>
heat, nah, libgcc just detects the features in the headers and use them
<gog>
hi barbie
<sortie>
And the cycle is resolved at link time when statically linking
<heat>
yeah bbbut libgcc_s
<sortie>
Can you do a no-actual-linking dynamic linking?
<sortie>
Or maybe just generate a fake stub libc.so?
<heat>
it may be possible to manually coerce the libgcc build into that
<sortie>
Should be doable with a cross binutils that you already got that point
<sortie>
Or maybe build libgcc_s in a follow up step?
<sortie>
Or just always keep libgcc static? idk if the shared stuff is worth it
<heat>
note that that can probably get hairily annoying if glibc (symbol versioning, slightly different ABI, ifuncs, etc)
<heat>
idk if the shared stuff is worth it either
<sortie>
libgcc_s.so will probably complicate the dynamic linker for libc.so itself
air has joined #osdev
<sortie>
Since everything -> libgcc_s.so
<sortie>
Including libc.so which makes it the non-root in the graph
<Arsen>
libgcc and libc link eachother
<heat>
libc.so is not guaranteed to be a root graph though
<sortie>
Yeah I guess that's libgcc kinda, although actual cyclic
<heat>
also: libc can't link libgcc dynamically im pretty sure
<sortie>
Least with musl and Sortix libc, the libc binary contains all of the libc stuff including pthreads and rt
<sortie>
(except Sortix still has libm)
<heat>
glibc too now
<heat>
except ld.so, that's still separate
<geist>
maf is hard
<sortie>
libc.so can totally link libgcc_s.so dynamically if do it yourself in your dynamic linker, question is whether you bother
<heat>
no because libgcc_s.so will depend on libc.so
<heat>
hence FUCK
<sortie>
I'd probably be inspired by musl and make libc.so the dynamic linker
<heat>
you get a cycle
<sortie>
heat, well you load both and resolve the cycle
<sortie>
If you bother and want to
<heat>
hmm right
<Arsen>
23:12:10 <heat> also: libc can't link libgcc dynamically im pretty sure
<Arsen>
it can
<Arsen>
but i don't think anyone does actually
<heat>
you're required to handle cycles?
<Arsen>
so disregard that
<sortie>
For Sortix, I'll probably stick with static libgcc (at least for libc) and then have libc.so contain everything and also be the dynamic linker
<sortie>
heat, if you want cycles, yeah
<sortie>
For big applications you'll probably have cycles too
<heat>
well, it's not a wanting-situation. are you required to handle cycles by ELF and/or real world?
<sortie>
I think so
<heat>
i am honestly not sure
<heat>
but if Arsen says so
<sortie>
-lfoo -lbar can mutually depend on each other under shared linking
<Arsen>
yeah that
<sortie>
You can totally do cycles if the dynamic loader is it's own library
<sortie>
*is its own executable
<heat>
you can do them anyway
<sortie>
If you make libc.so the dynamic linker though, then it needs to be runnable on its own without needing any dependencies
<sortie>
That's probably the approach I will take
<heat>
early ldso is super brittle as you're half-relocated
<heat>
heck, you relocate yourself in the first place
<sortie>
I need to read up on this stuff. For Sortix, I'd probably teach the kernel how to load a dynamically linked executable without dependencies, and then use that to load libc.so directly as the dynamic linker and libc in one go, and then use it to load the real executable and its dependencies
<sortie>
Keep it simple and efficient with a hint of custom kernel support to make life easier and better
<heat>
kernels just don't relocate things
<heat>
relocation is annoying and hard to do from the kernel side
<sortie>
It should be all position independent anyway, right?
<heat>
except most of .data
<sortie>
So the kernel can just mmap libc.so to a random address and run _start
<heat>
sure, and traditionally PIE executables (ldso included) relocate themselves
<sortie>
.data is a good question
<heat>
also PLT stuff, GOT stuff
<heat>
RELATIVE relocs are easy to do but... why bother from the kernel side?
<heat>
then some new relocation pops up and your kernel is not up to date and spits your new exec out
<geist>
side note: if you're using clang the 32bit rel-vtable thing we're using in fuchsia is pretty neat
<geist>
really helps on the amount of rel updates you have to do with C++ code
<heat>
is it stable enough for a default?
<geist>
well, its ABI breaking so i wouldn't make it default
<geist>
it's more of the platform default
<geist>
or more to the point it's something a triple should opt into
<sortie>
heat, at least I version the kernel and compiler together since I'm mono repo
<sortie>
You bring up good points
<heat>
doing things in the libc is hard and annoying but also makes sense
<heat>
kernel should be simple
<heat>
libc can crash all it wants
<sortie>
heat, that's one area where we disagree
<sortie>
Linux has the approach where the kernel does its thing and libc has to figure stuff out on its own without much help, and it doesn't work that well
<sortie>
I have the approach where the kernel helps libc with the needed features such that the overall implementation is much simpler, safer, and faster
<heat>
safer? im not too sure
<sortie>
I'm unclear where that principle will lead me when I implement this, especially with the good points you bring up
<sortie>
heat, yeah I have completely eliminated the weird early bootstrap phase in libc.a, all features are online already at _start including errno
<sortie>
Not having weird early phases reduces complexity and potential bugs
<heat>
reduces complexity in the libc for sure, but you pass it all to the kernel
<sortie>
Nah like I said, reduces overall complexity
<heat>
geist, btw does an arm64 booting in EL2 mean it supports KVM? or is there another requirement?
<Arsen>
at the expense of safety in the far more critical component?
<sortie>
Otherwise thread local storage in libc required opening the ELF executable to locate and map it as a bootstrap phase, but with kernel help (and it already parsed and loaded the executable), boom it's not needed and overall complexity goes down in this case
<sortie>
And makes static linking even smaller
<geist>
heat: on linux in general yes, but i remmber on rpi 3 or 4 there was the additional requirement that you've configured it to use the builtin arm time
<geist>
timer, vs the broadcomm timer hardware
<geist>
one of those boot.ini options or something
<geist>
but in general aside frmo that case i think yes
<heat>
i *may* have KVM on my rpi zero 2 w then
<heat>
CompanionCube says his rpi3 has KVM
<heat>
# CONFIG_VIRTUALIZATION is not set :/
<geist>
yeah also depends on what distro you're runnig. i'm usually running ubuntu, which has all the bells enabled
<geist>
raspbian probably does not enable it
<heat>
im on alpine
<geist>
probably even running in arm32 mode
<geist>
oh dunno alpine, but yeah in general it should work, with the arm native timer the other exception
<geist>
and 64bit kernel of course
<heat>
the gang builds a new kernel
<geist>
i default have and still do run kvm on my rpi4
<heat>
KVM support means ONYX ARM64 ON NATIVE BAYBEEEEEEEEEEEEE
<geist>
so it certainly can
<geist>
oh fun thing i read today: folks are finding rpi4s in abandoned scooters in Seattle
<geist>
one of the scooter makers went out of biz and apparently left some hardware floating around, and each one has a rpi4, so folks are scavenging them
<bslsk05>
raspberrypi/firmware - This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware. (1672 forks/4867 stargazers)
<CompanionCube>
looking at the modules.builtin shows 'kernel/arch/arm64/kvm/kvm.ko' so that's pres
xenos1984 has quit [Read error: Connection reset by peer]
<CompanionCube>
so that's almost certainly a yes?
<geist>
probably. easiest way to tell is via the presence of /dev/kvm
<geist>
also like i said there was some sort of boot.txt or whatnot in the FAT partition that iirc you need to make sure it doesn't select the BCM timer
<geist>
since KVM needs the built int arm-architectural timer to work properly
<geist>
i dunno if that's still a thing, but it was at the time i was trying to enable my rpi4
* CompanionCube
once used that repo's kernel to try out arm64 without reinstalling the whole OS, but i have lost that sdcard since
<geist>
for some historical reason the rpi kernel seems to like using the BCM timer first, which is some external hardwar e(to the core) instead of the default one
<geist>
i think it's for some sort of media playback reason
vinc has quit [Read error: Connection reset by peer]
* CompanionCube
sees arch_timer/arch_sys_timer being used, but the irq for it in /proc/interrupts references bcm, so unsure which that is, since there's not another timer i can spot.
<heat>
geist, knowing the BCM chipsets it probably releases radioactive isotopes every time you arm the ARM timer
xenos1984 has joined #osdev
<froggey>
psci is the way to go for detecting/booting cpus on aarch64, right?
SGautam has quit [Quit: Connection closed for inactivity]
<linkdd>
i ended up writing my own std::atomic, and not include the problematic header, leaving the problem of the toolchain for future me (i trust him, he's good)
<heat>
froggey, yea
<heat>
not sure about detecting (device tree tells you all that, no?) but certainly for booting em
<heat>
linkdd, good choice
<heat>
std::atomic is the least of your worries, it's just __atomic_* encapsulated
<heat>
type_traits is fucked up as you depend on __builtins that aren't even documented
<linkdd>
yes, and i'm not ready yet to give up on initializer_list, or type_traits
<gog>
hi
<linkdd>
at some point, i'll just git submodule the llvm project, and build the toolchain as part of my build system. i use cmake and they use it too, so the pain will be at choosing the right build options.
<linkdd>
that's what SerenityOS does
<linkdd>
they also have their own patches to add support for their target triple to llvm
<heat>
problem2: ideally it'd get its own quarantine? i don't know
<heat>
problem3: i could use the page allocator but, again, nothing would feed back into the pcpu lists. but there would be a large win from having some in the first place, i assume
* mjg
burps
<mjg>
have you tried running trinity yet
<mjg>
or are you going striaght for syzkaller
<heat>
why I don't use the page allocator + direct map directly: i had perf regressions from using the direct map, and it doesn't support KASAN yet
<heat>
i have not thought about that for a long time
<mjg>
maybe run the ltp suite
[itchyjunk] has joined #osdev
<mjg>
it wont work, but the q is if your kernel will panic
<heat>
will probably finish my local work, go for RCU, then either arm64 or basic read/write stability
<heat>
as soon as I have that, it's pretty usable
<heat>
it just needs a good rework on dirty/writeback paths
<mjg>
lol check out this mofo + REQUIRES(mm->vm_lock)
<mjg>
faken' locking annotations
<mjg>
you are better than linux for the most part
gog has joined #osdev
<zid>
glorg, spawn of the underlords, has returned!