foudfou_ has quit [Remote host closed the connection]
foudfou has joined #osdev
theruran has joined #osdev
gog has quit [Quit: byee]
navi has quit [Ping timeout: 256 seconds]
srjek has quit [Ping timeout: 252 seconds]
voidah has quit [Ping timeout: 260 seconds]
zetef has quit [Remote host closed the connection]
<kof673>
> Disk space is cheap, and better yet, the BeOS R4 CD comes with a special version of Partition Magic (for 9x and NT) that can aid you in your
<kof673>
they may have just been trying to not require that ;D
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
<kof673>
i believe the reason was it could resize an existing filesystem without destroying the data
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
<heat>
so i've just used quilt
<heat>
very quaint stuff, but actually useful
dasabhi has joined #osdev
<dasabhi>
hello
<dasabhi>
geist: how have you been
theruran has quit [Quit: Connection closed for inactivity]
<dasabhi>
hey what happened to freenode, whats the drama over it
<dasabhi>
is the fuchsia irc still active on freenode?
<heat>
woah that was a long 3 year nap wasn't it?
<heat>
no, fuchsia moved to discord
<dasabhi>
have i been out for 3 years? :P
<heat>
>On 19 May 2021, Freenode underwent what some staff described as a "hostile takeover"[4] and at least 14 volunteer staff members resigned.
<heat>
almost!
<dasabhi>
irc logs on libera.orc.log update in real time
<zid`>
disregard irc, level paladins while listening to audio books
<kof673>
lee thought he could avoid conway's law...you see what happens? lol
ZombieChicken has joined #osdev
dasabhi has quit [Quit: Lost terminal]
ZombieChicken has quit [Client Quit]
Arthuria has quit [Ping timeout: 268 seconds]
wlemuel has joined #osdev
<geist>
3 years!
<zid`>
next week: Hey guys, I hear linux is finally moving away from 2.6.x numbering
<heat>
this linux 2.6 thing doesn't look stable, i'll stick with 2.4
<zid`>
did 2.6 ever cut a 2.6-stable
<zid`>
2.6.39.4 doesn't count
dasabhi has joined #osdev
<dasabhi>
geist:hello!
<geist>
yo
<dasabhi>
geist: how is everything in seattle
<dasabhi>
i heard from a friend that used to be on your team that everything is still fine on the kernel side
<dasabhi>
heard it was userspace that got demolished in 2023
<geist>
ah
skydhash has joined #osdev
<dasabhi>
hey does any one know the vdso equivalent on freebsd?
<dasabhi>
wondering if syscalling as complicated on bsd as it is in linux
<geist>
commpage is i think what BSDs call it
<dasabhi>
commpage got it, thanks
<heat>
linux syscalling is complicated?
<dasabhi>
it is when you are a noob
<heat>
step 1) know the syscall nr you're calling 2) set up the regs 3) syscall instruction on x86_64
<heat>
step 4 profits
<geist>
i386 i guess it's kinda complicated because th emultiple mechanisms
<heat>
yeah i386 is garbo but you can just int $0x80 and let it rip
<dasabhi>
so is the vdso sector the exact same setup like the trampoline in xv6?
<dasabhi>
because if its not, then it is more complicated lmfao
<heat>
what's the trampoline?
<dasabhi>
i am basing everything off xv6 right now
<bslsk05>
github.com: xv6-riscv/kernel/trampoline.S at riscv · mit-pdos/xv6-riscv · GitHub
<heat>
the linux vdso is a .so thats shipped embedded in the kernel and gets auto-loaded for every process
<heat>
the freebsd commpage sounds like the linux vsyscall page which is basically a shared page with some little hacks for some syscalls, and maybe a common syscall mechanism if you're (un)lucky
<dasabhi>
doesnt that sound like the trampoline with less steps?
<dasabhi>
trampoline is in every process in xv6
<heat>
the trampoline is part of the kernel
<dasabhi>
ahh
<dasabhi>
okay
<heat>
every kernel has this, vdso-less or not
<dasabhi>
let me check the docs, i could have swore i saw trampoline in userspace for every process
<heat>
ugh they have split user-kernel address spaces?
<heat>
awful, awful stuff
ashad has joined #osdev
<heat>
i think i see where you're mixing things up
<dasabhi>
xv6 does map the trampoline page into every process
<ashad>
Hi
<dasabhi>
but yes the trampoline does technically live in the kernel
<dasabhi>
ashad here did xv6 on x86
<heat>
dasabhi, because xv6 has a dumbass virtual addressing policy where kernel and user are completely separate
<dasabhi>
ashad how does the trampoline work in xv6 wth x86
<heat>
wait a sec, is this just meltdown mitigations?
<heat>
did they stick meltdown mitigations in a teaching OS?
<dasabhi>
heat: what do you mean kernel and userspace are seperate? isnt that the point? :S
<dasabhi>
i dont think so lol
<heat>
no, that's not the point
<heat>
the usual set up (pre-meltdown) is to have the kernel and user share page tables
<heat>
and avoid the silly address space switching in and out the kernel
<heat>
yep, there's no sillyness in x86 xv6
<heat>
so what i suspect happened is that they thought, yep, doing meltdown mitigations is a great idea for a teaching OS
<heat>
on an arch that was never affected by meltdown in the first place
<heat>
cannot wait for the next episode of xv6-riscv where they flush the branch target buffer on a cpu that has no branch prediction at all
wlemuel has quit [Remote host closed the connection]
<dasabhi>
so xv6 riscv which is what i am doing, does share the page between kernel and userspace
<dasabhi>
it maps the page into every process and its used to perform a syscall, but its the same page
<dasabhi>
no fancy switching as far as i can tell
<dasabhi>
heat: no where near branch target buffer flushing yet ahaaha
heat has quit [Ping timeout: 268 seconds]
wlemuel has joined #osdev
ashad has quit [Remote host closed the connection]
dasabhi has quit [Quit: Lost terminal]
<immibis>
since all your data are belong to some variation of spectre, may as well just use one address space as much as possible and save the performance hit
goliath has joined #osdev
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 252 seconds]
skydhash has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
wlemuel has quit [Remote host closed the connection]
vin has quit [Quit: WeeChat 2.8]
agent314 has quit [Read error: Connection reset by peer]
agent314 has joined #osdev
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
op has joined #osdev
GeDaMo has joined #osdev
gbowne1 has quit [Quit: Leaving]
agent314 has quit [Read error: Connection reset by peer]
gog has joined #osdev
scaleww has joined #osdev
wlemuel has joined #osdev
bitoff has quit [Read error: Connection reset by peer]
wlemuel has quit [Ping timeout: 268 seconds]
scaleww has quit [Remote host closed the connection]
<ddevault>
hrm, gcc --sysroot does not seem to work
<ddevault>
or at least, gcc --sysroot=path/ does not find path/usr/include/stdio.h
<GeDaMo>
Could it be the trailing slash?
<ddevault>
nope
<ddevault>
with or without, makes no difference
<kof673>
does it need a full path?
<ddevault>
no, I narrowed it down a bit
<ddevault>
`x86_64-elf-gcc --sysroot=target/root/ -E -Wp,-v -` (thanks stackoverflow) does not include usr/include from anywhere at all
<ddevault>
gcc configuration issue I think
<kof673>
there is a -dumpspecs or was but i don't know all how that works
<ddevault>
I'd sooner kill myself than try to parse the output of gcc -dumpspecs again
<ddevault>
anyway
<ddevault>
I'll just add -I for now
<ddevault>
sometime later I'll do a proper cross compiler targetting my OS
<bslsk05>
wiki.osdev.org: Meaty Skeleton - OSDev Wiki
<sortie>
“The -elf targets have no user-space and are incapable of having one. We configured the compiler with system root support, so it will look in ${SYSROOT}/usr/lib as expected. We prevented the compiler from searching for a standard library using the --without-headers option when building i686-elf-gcc, so it will not look in ${SYSROOT}/usr/include. (Once you add a user-space and a libc, you will configure your custom cross-gcc with --with-sysroot and it wil
<sortie>
l look in ${SYSROOT}/usr/include. As a temporary work-around until you get that far, we fix it by passing -isystem=/usr/include). “
<bslsk05>
wiki.osdev.org: Hosted GCC Cross-Compiler - OSDev Wiki
<bslsk05>
wiki.osdev.org: OS Specific Toolchain - OSDev Wiki
<sortie>
Basically the -elf targets are super generic and you want to replace it with a toolchain dedicated for your OS around the time your user-space starts being a real thing
<sortie>
ddevault: Until then --sysroot=sysroot -isystem=/usr/include is the right solution
<sortie>
The --isystem= is relative to the supplied sysroot btw
<ddevault>
thanks sortie
<sortie>
I may have written all of those tutorials haha
<sortie>
ddevault: I encourage you to study meaty skeleton, it shows how to set up the system root, standard library, headers, etc. in a good way and how to cross-compile with the sysroot in a clean and simple fashion
<kazinsal>
noob: using local gcc
<kazinsal>
less noob: compiling a new cross utils
<kazinsal>
bored researcher tier: just running geist's ./doit
<ddevault>
I have done an OS-specific gcc for a different OS
<ddevault>
but I'd like to defer that for now on this project
<kazinsal>
cloning travisg/toolchain and smashing ./doit is one of my semi-annual rituals at this point
<sortie>
Compiling gcc natively is such a mind fuck of 'wait how is this even possible'
<ddevault>
I have 8 gcc builds in ~/sources -_-
foudfou has quit [Remote host closed the connection]
<sortie>
ddevault: Yeah I intentionally structured all of these tutorials so the gcc next-level stuff was all done at healthy points in the project life cycles when people had enough experience and also didn't do it too early where it would be overwhelming or just didn't have enough benefits
foudfou has joined #osdev
<nikolapdp>
yeah geist's toolchain script is pretty neat
<nikolapdp>
i've used it to make a hare cross compiler heh
<bslsk05>
wiki.osdev.org: GCC Cross-Compiler - OSDev Wiki
<bslsk05>
wiki.osdev.org: Porting GCC to your OS - OSDev Wiki
<bslsk05>
wiki.osdev.org: Cross-Porting Software - OSDev Wiki
<ddevault>
SophiaNya: nice
<ddevault>
sortie: nice*
<kazinsal>
level 5: ./doit
<sortie>
Level 4 basically needs you to port a ton of stuff like make, a shell, a bunch of utilities, and whatever local programs are needed to build gcc -- plus your OS and standard library has to be correct enough
<nikolapdp>
just do it man
<kazinsal>
my two gimmick osdev hackery projects are, separately, a router and a Fourth Edition Unix for the IBM PC XT
<kazinsal>
neither of which lend themselves to running a compiler
<bslsk05>
wiki.osdev.org: Bare Bones - OSDev Wiki
<nikolapdp>
did you do managing before writing that article
<nikolapdp>
or after
<sortie>
Yes
<nikolapdp>
lol yes what
<sortie>
Definitely one or the other
<kazinsal>
I'm technically a formerly permabanned poster :(
<kazinsal>
it's okay though, I got better
<sortie>
kazinsal: Did I mention I ported phpBB to Sortix the other day and set up a test osdev forum?
<sortie>
You are of course welcome over there
<kazinsal>
lmao, probably works better than our actual forum
<sortie>
As soon as I figure out how to port the registration system
<kazinsal>
flashbacks to everyone going "hey, DNS is dead" and chase just not existing
<sortie>
kazinsal: lol, not quite yet, nginx <-> php integration is a little flaky, has a little bug that I may have solved now (I need to test)
srjek has joined #osdev
<sortie>
Haha yes chase is absolutely the reason I am the literally setting up my own competing osdev infrastructure
<sortie>
I'm literally running an #osdev channel on my own self-hosted IRC network, looking into porting phpBB and mediawiki, so we have a future evacuation route that is powered by osdev
<kazinsal>
at one point we at least had klange holding down the fort but they seem to no longer be around
<sortie>
I'm afraid to open the forum at this point
<sortie>
I trust somebody is dealing with it
<sortie>
At least the wiki seems good
<sortie>
#if defined(__linux__)
<sortie>
#error "You are not using a cross-compiler, you will most certainly run into trouble"
<sortie>
#endif
<kazinsal>
most of the old guard seem to be gone at this point
<kazinsal>
really it's you, me, and the g-man
<sortie>
^^^ The best three lines I ever wrote. You'd be surprised how many people failed to just remove those three lines when they got the error and ended up actually doing a cross-compiler.
<sortie>
kazinsal: right, I'm an x-g-man now :|
<kazinsal>
you're no longer with big G?
<sortie>
Got caught up in the last round of layoffs
<kazinsal>
shit, sorry man
<sortie>
In bright news, six month paid severance
<kazinsal>
good stuff
<kazinsal>
I got a month's worth before coming into my new job
<kazinsal>
only because they didn't want me around lol
<kazinsal>
put in my notice and got a call an hour later telling me they'd send me a box to ship my laptop back
<mjg>
quitting a job is something i'm alwaywas going to recommend
<bslsk05>
github.com: mini-rv32ima/mini-rv32ima at nix · cleverca22/mini-rv32ima · GitHub
<heat_>
why am i shilling for zfs
<clever>
heat_: nommu rv32, i'm not sure the zfs userland tools would build with that
<clever>
i'm not even sure if the zfs kernel will be happy with a missing mmu
<ddevault>
tip if you're struggling with memory allocation in doom
<clever>
xfs journal replay already barfs when the mmu is missing
<ddevault>
just statically allocate everything it wants
<nikolar>
ZFS ZFS ZFS
<heat_>
do you think zfs can't deal with less than 32GB of ram?
<ddevault>
also a good way to skip the filesystem bits, I just baked the wadfile into .data
<nikolar>
heat_ I'm running ZFS on my 8gb ram laptop
<nikolar>
No issues whatsoever
<clever>
ddevault: for disks under 1tb, ext4 has zero trouble, so filesystem isnt a problem
<clever>
>1gig of ram on a 32bit kernel is a problem
<clever>
zfs wants all of the ARC mapped into the kernel virtual space
<ddevault>
well, the last time I ported doom I had a framebuffer driver and a keyboard driver and nothing else
<ddevault>
so I needed to avoid the filesystem, eh
<clever>
and with a 3g/1g split, that cant fit
<clever>
ddevault: ah, i found virtio-blk simpler to implement then virtio-input
<clever>
blk only issues requests one at a time, so its easier to understand the ringbuffer
<ddevault>
I was targeting real hardware, PS/2 and a multiboot fb
<clever>
input floods the ring until its full, and then you cant make sense of where the read and write ptr's are
<heat_>
blk doesn't issue a request at a time?
<clever>
heat_: during boot, the partition probing code issues a single requests, and waits for a reply, and even halts the boot
<heat_>
anyway i'm starting to think i need a FAT driver
<heat_>
fucking kill me
<clever>
and after that, its a 1:1 mapping from whatever you read()
<clever>
so you can watch the ringbuffer advance slowly
<ddevault>
you need a FAT driver if you intend to manage an EFI system partition from within your OS at some point in the future
<ddevault>
main reason I intend to write one
<heat_>
i know
<clever>
input just fills the ringbuffer to 100% instantly
<heat_>
my grub-install on BIOS is coming out borked when booting
<heat_>
i... i don't know how to debug this, i'd hope GRUB on EFI is easier to diagnose if shit hits the fan
goliath has joined #osdev
<clever>
i would say, can you repro under qemu or bochs?
<heat_>
that's what i'm using yeah
<clever>
qemu can single-step and print regs, and gdb can attach to it, but gdb is kinda confused with real mode
<heat_>
i'm not debugging GRUB lol
<gog>
degrubbing
<heat_>
would rather die that to single step and disassemble GRUB real mode code
<clever>
ive had to single-step my way thru a custom bootloader and the entire pre-mmu stage of linux before
<heat_>
in theory my data looks good.... the page cache matches up with the disk, so it's not a writeback problem
<clever>
turns out, when linux is built with SMP support, the printk's are guarded with mutexes (duh!), but on an rpi2, the mutex opcodes are optional, and disabled by default
<heat_>
could be a page cache problem, but i don't think i have any
<clever>
so, the instant linux is done switching to virtual mode, it switches from a single-threaded print to a thread-safe print, and throws an exception
<clever>
and the exception table hasnt been setup yet
<nikolar>
Oh that's silly
<clever>
so it jumps to $UNDEFINED
<clever>
and its purely concidence, that the first printk it attempted, mentions SMP, lol
<nikolar>
Ironic
<clever>
also, by a huge stroke of luck, the control bit on a pi2, that enables SMP, fixed a totally unrelated problem on the pi3
<clever>
on the pi3, that bit instead allows non-secure kernel to flush the L2 cache
<clever>
and without that, linux gets as far as /init, then all hell breaks loose
<clever>
and major memory corruption comes stomping in
<clever>
so my sloppy code (applying the pi2 SMP fix to everything), wound up fixing the pi3 issue i hadnt figured out, lol
<nikolar>
Lol silly
<nikolar>
Arm is such a mess of a platform
<clever>
this is all in the implementation defined stuff, that varies with every core
<nikolar>
Yeah exactly
<clever>
where you really should have read the manual, and understood every register
<clever>
but how am i to know, that ram corruption means L2 cache permission problems? :D
<clever>
i also need to investigate the systick config again
<clever>
because i told linux it was 1mhz, but it somehow became 19.2mhz yesterday
<clever>
and then systemd got upset about sshd taking too long to start, because time was on fast-forward!
<heat_>
arm isn't a platform, that's the problem
<nikolar>
Yes exactly
<clever>
bbl
<heat_>
bbl drizzy??
<mjg>
heat i have a problem
<mjg>
"kentucky fried chicken"
<mjg>
how much is it?
<mjg>
plural form without the counter?
<heat_>
plural
<mjg>
how many chickens is it
<heat_>
i dont know how many chicks there are
<heat_>
but they are plural that's for sure
<ddevault>
what's the best place to start for sh(1)? anyone know of a simple implementation with optional build-time job control?
<ddevault>
just gonna start with dash if there aren't any better ideas
<nikolar>
I think dash was the best option for that
<ddevault>
gah! autotools!
netbsduser has joined #osdev
<nikolar>
Heh
<ddevault>
good god they don't even pre-generate the autoshit in the release tarballs
<heat_>
hold the fuck up
<heat_>
when generate them, oh no supply chain jia is going to get us
<heat_>
when they don't, oh no the gnu dumbasses don't do the obvious thing
<heat_>
which one is it people?!
<ddevault>
don't pre-generate anything but autotools
<ddevault>
but if you save me from autohell I appreciate it
<ddevault>
ideally just switch to a sane fucking build system
<ddevault>
ah, no, they do pre-generate, I ended up with a tarball from git archive
chiselfuse has quit [Remote host closed the connection]
<nikolar>
Heh
chiselfuse has joined #osdev
<clever>
back
foudfou has quit [Remote host closed the connection]
<nikolar>
Hello clever
<nikolar>
Any more cursed bugs you want to share
foudfou has joined #osdev
<clever>
nikolar: let me see...
<clever>
nikolar: in the dwc2 usb controller, when acting in device mode, there are some control registers for each endpoint
<clever>
in the publicly available documentation, one of the registers contains a byte count and packet count
<clever>
and the rules are kinda complex
<clever>
if the max packet size is say 64 bytes, and you want to send 128 bytes, thats 128 bytes and 3 packets
<clever>
because a transfer is always terminated by a packet not being the max size, and you may need a 0 byte packet to finish it off
<clever>
but surprise, endpoint 0 only ever accepts a packet count of 1
<clever>
the public docs make zero mention of that
<nikolar>
Oh yuck
<clever>
once you realize that limitation exists, its easy enought to code around, queue up just 1 packet at a time, wait for the completion irq, and then queue up the next packet
<clever>
but now you pay an entire round-trip thru the irq handler between each packet
<nikolar>
Yeah, not good
<clever>
another weird hw quick, i believe in non-dma host mode, reading from an HID endpoint that isnt ready (no keys pressed) results in a NAK and it halts
<clever>
so you need to schedule a timer to retry again at a later time
<clever>
but i think in dma mode, it doesnt do that
<clever>
any interrupt endpoint*
<clever>
also, the hardware has basically zero support for isochronus endpoints (usb audio/video), you have to do all of that in software
gbowne1 has joined #osdev
<netbsduser>
unbelievable how easy nullfs (what linux calls "bind mounts") becomes when you separate vnodes from namecache and have mounts be a namecache-level thing
<geist>
yah linux's pervasive namecache thing is interesting
<geist>
that as something i never did back in the day. the older VFS designs the dir cache was just an external accellerator to keep it from needing to keep grabbing inodes as you walk through the tree
<geist>
but linux sort of inverts that whole thing
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
gog has quit [Quit: byee]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
<netbsduser>
geist: i really like it and i have fully committed to the design
<netbsduser>
dragonfly bsd has it too
<netbsduser>
there are so many other benefits as well
gildasio has quit [Ping timeout: 260 seconds]
<geist>
seems like it ought to make inodeless FSes like FAT easier to implement too
<geist>
since you dont really need there to be a unique inode #, etc (except maybe for posix stat purposes)
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
<clever>
now that you bring that up, how does fat even emulate an inode#??
<clever>
first block in the chain could work, but only if your doing in-place changes to the file
<nortti>
I remember geist talking of how they did it in beos before, iirc it was the dirent location at the mount time?
<geist>
well, it doesnt but on windows the VFS was always 100% path based, so the concept of an inode # was not important
<geist>
so for inode # based vfses yeah you have to synthesize the inode #
<geist>
i think it was the dirent location yah, and then the beos code never repacked the directories such that the location would change
<clever>
ive had bugs before, with zfs and virtio-9p, where directories got cross-wired somehow
gildasio has joined #osdev
<clever>
so when you read dir a, you get dir b's contents
<nortti>
how do hard link works on windows?
<clever>
i didnt get the exact details of how that even happened
<nortti>
or is that something that doesn't get handled on the vfs level?
<geist>
nortti: NTFS does have essentially inode #, it's just hidden a layer below
<geist>
so a FILE record can be pointed to by multiple dirs
<geist>
but then they also have Reparse Points which is a higher level notion, though i guess thats a symlink now that i thinkl about it
gog has joined #osdev
<geist>
but since the windows VFS is basically path based all the way, a hard link i think works out just fine
<geist>
question is how does the vfs handle multiple paths getting to the same underlying file. perhaps a namecache like thing
<nortti>
I guess the NTFS driver itself is then responsible for keeping accesses through the two different paths that point to the same FILE coherent?
<geist>
or there's some VFS support for hardlinks by having the FS return a pointer to an existing FILE record that the VFS at least handles
<geist>
the windows VFS, etc is so alien to folks that have worked in unix fses
<geist>
it's like a bizarro alternate world where every decision was the other way
<geist>
has some advantages and a lot of disadvantages
<geist>
even within windows FSes it seems like multiple universes, since there are the classic DOS things (fat, fat32, etc) and then NTFS which came from an alien planet (openvms)
<nikolar>
and also refs
<geist>
and i guess refs if that ever gets any play
<netbsduser>
i don't think what windows has can even be called a VFS
<nikolar>
i think windows server uses refs by default
<nikolar>
not sure
<geist>
i think they call it something like FSIL (file system interface layer)
<geist>
i actually have the NT file syste internals book. they published back in the day and it's completely unobtanium now
<netbsduser>
there is no vnode equivalent as far as i know, there are file objects and there are one per each open of an underlying fs node
<nikolapdp>
heh
<nikolapdp>
scan it and post it on the internet archive geist :P
<netbsduser>
and i think one might be designated as a master where the section object pointer (vm object equivalent) and other stuff is held
<geist>
i wonder if the pdf exists already
<geist>
netbsduser: but yeah they'd have to handle multiple dir paths getting to the same file object. maybe as you say NTFS does the trickery behind the back of the FSIL
<geist>
but then you'd have caching issues, since they cache at the file level
<geist>
so there has to be *something* that allows multople open files from different paths to get to the same underlying file object
<geist>
one layer of indirection, maybe optional
<geist>
like some sort of stand in file record that just poits to another one
<netbsduser>
windows nt is undoubtedly a kernel of wonderful structure, and like unix it has a distinguished lineage (nt spiritually descends from vms itself!), but i think FS stuff in it is worse off here
<netbsduser>
it is one of the areas where unix was able to do better
<netbsduser>
geist: this is where the master file (i might be hallucinating this concept) comes in, i think
<geist>
agreed. i've also been told by folks that have worked at msft that ntfs.sys is a complete disaster of a codebase
<geist>
one of those very old skool C codebases that is impossible to work with, but it is apparently rock solid so no one will touch it
orccoin has joined #osdev
orccoin has quit [Client Quit]
<acidx>
geist: back when I was at msft, when they moved some font stuff from some crusty old C codebase to rust, the person that did the work made a really nice presentation about the conversion work. it was essentially done in steps, as in "convert everything as is, don't try to make it look like rust, make sure we add tests as we go along comparing with the DLL written in C, and when things are working, start
<acidx>
cleaning it up)
<geist>
yah that's the right way to do it
<acidx>
yeah, and it was a really nice talk. wish they had made it public
<geist>
we have converted a lot of C to C++ and that's a good strategy to follow
<geist>
that way every step is a single apples to apples comparison
<acidx>
yup
<acidx>
takes a long time, but it's worth it
<acidx>
especially when hand-optimized code written for early 90s compilers end up becoming straightforward idiomatic code that ends up getting better codegen due to 30+ years of compiler improvements
<FreeFull>
Microsoft originally seemed to want to bring ReFS to everybody, but then changed their mind and made it enterprise-only
<netbsduser>
i wonder why they changed their minds
<nikolar>
product separation i imagine
<FreeFull>
Windows doesn't even seem to make full use of NTFS
<nikolar>
heh
<ddevault>
86_64-elf/bin/ld: cannot find -lg: No such file or directory
<ddevault>
uh
<ddevault>
passing -g to gcc
<geist>
sup g
<ddevault>
anyone seen this one?
<geist>
no, but no context to figure out what you're doing there
<ddevault>
fair enough
<ddevault>
goes away when I split up building and linking into two gcc invocations
<geist>
but no, -g shouldn't do that, so there must be something going on you that isn't obvious
<geist>
i generally do that *anyway*
<ddevault>
I was being lazy
<ddevault>
¯\_(ツ)_/¯
<geist>
when linking kernel stuff at least. because then you take full control
<ddevault>
this is for userspace
<geist>
vs using the gcc front end to the linker, which has a lot of built in rules
<geist>
well, i mean for your os
childlikempress is now known as Mondenkind
remexre has quit [Remote host closed the connection]
remexre has joined #osdev
<geist>
i think the general idea is if you're driving gcc arch-elf for your OS, do the gcc -c and ld link phases separately in your build system to manually drive it
<geist>
but at some point you may make yourself a custom triple in gcc, in which case you can then bake in a bunch of decisions about how to link things
<geist>
in which case then userspace would be much more amenable to using gcc without the separate link
<geist>
since in that mode it acts like a front end for both tools
<heat_>
-g making you link against a special libc is Traditional Behavior
<heat_>
mayb x86_64-elf has that in the spec file
<heat_>
ie instead of looking for libc it looks for libg
<geist>
aaahso there ends up literally being a libg.so that its looking for?
<heat_>
yeah
<geist>
TIL
<Mondenkind>
huh, why?
<heat_>
libg would be a debug-symbol'd libc
<geist>
well makes sense, having a debug libc would maybe make sense
<geist>
but calliung it 'libg' is just lazy
<heat_>
or maybe even a debug libc, i'm not too well versed in that
<geist>
at least call it something like libcg or libc-debug or something
<heat_>
same thing happens for other variants. iirc adding profile flags made it look for libc_pg or some weird variant like that
<heat_>
oh no, it looked for a different crt0/1.o variant, i think that's what it did
<heat_>
(to set up profiling)
<geist>
but yeah this is all part of the front end, triple part of the compiler front end
<geist>
where it's deciding all these default switches and behavior
<heat_>
>FlexOS, 4680 OS, 4690 OS, Multiuser DOS, System Manager, REAL/32 and DR DOS 6.0
<heat_>
like, i just want something that can interop with windows and efi and linux
<heat_>
i don't want to know about 69420 DOS
<heat_>
ugh maybe i should just take freebsd's driver
<heat_>
just so much code for a filesystem i do not want to write at all
<Mondenkind>
would you really be able to live with yourelf if you put freebd code in onyx
<heat_>
hmmm. it might scare the users away, good point
<nikolapdp>
what users
<Ermine>
heat_: what about sortix driver?
<sortie>
heat_, my driver is actually not a bad resource to look at
<nortti>
I forget, did you implement FAT16 too, or is it FAT32 only still?
<netbsduser>
heat_: i implemented the basics of a (currently read-only) driver from the description in the uefi fat32 spec
<netbsduser>
it also describes FAT12 and FAT16
<netbsduser>
i transcribed parts of it almost directly
<netbsduser>
writing directory entries turns into a hateful game when you have to write LFNs because you have to repeatedly modify the proposed shortname until you can find no instance of a file under that shortname
<netbsduser>
the principle merit of implementing FAT appears to me to be how desperately a FAT driver demands you employ clever strategies to make it even vaguely efficient
<heat_>
nikolapdp, me and ermine
<heat_>
sortie, yeah but your codestyle is so anti-mine it'll be a poor fit probably
<heat_>
0 < open() is the kind of stuff that gives me shivers
<Ermine>
yoda style
<heat_>
netbsduser, oh, right, EFI documents FAT
<sortie>
nortti, it always had all the FATs supported, I did just skip out of a couple FAT12/16 special cases for a while, particularly for the root directory, but I think I implemented those since
<Mondenkind>
because the uefi spec has _definitely_ never made anybody cry..
<heat_>
what's worse, EFI TCP/IP protocols or extensive descriptions of how DONG-DOS and MS-DOS 420 used a field
<netbsduser>
it's fairly well written i had no issue with it
<netbsduser>
it's clearly the work of someone competent and articulate and not some windbag specifier
<netbsduser>
high prose it is not but readable and clear it is
<heat_>
>.doc
<heat_>
thanks though
<Ermine>
converting stuff to pdf is pretty handy
<netbsduser>
if it weren't for LFNs it wouldn't be too much of a hassle
<netbsduser>
those are annoying
<netbsduser>
but they justify them fairly in terms of forwards compatibility for old DOS
op has quit [Remote host closed the connection]
zxrom has quit [Remote host closed the connection]
zxrom has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
<kof673>
people (skims scrollback) :/ > tiki torch "tiki's hole" was e.g. equinoxen...it is just more endlessen eternalen illiteracyen lost in translationen lolen > The underworld or po was that part of Avaiki immediately below Mangaia which was reached originally through the chasm known as Tiki's hole
<mcrod>
hi
goliath has quit [Quit: SIGSEGV]
<heat_>
okay for anyone doing this after me: grub does not support clang nor ld.gold and silently generates borked installations
<heat_>
also thank you sortie for the rubberduck/guidance