<kazinsal>
looks like the chipset can do some VLAN offload stuff so I should be able to test that kind of magic'
<kazinsal>
just need to yank a decommissioned box from work
<kazinsal>
we moved to everyone having laptops mid covid, but left all our old desktops in the lab
<geist>
yeah i'm swimming in old machines. i usually pick the 'weirdest' one for osdev when i do it
<geist>
because why not
<Ermine>
Either fedora doesn't have mglru enabled or mglru doesn't help with memory pressure
<geist>
my current fave PC is a Kaveri AMD machine, because it's a bit weird
<kazinsal>
yeah, our deluge of machines is mostly 7-8th gen intel cores so pretty good workhorses
<Ermine>
kazinsal: consider making cluster out of all those desktops
<geist>
also the case has a lot of sharp edges and a stick that says 'speed demon' with it crossed out to read 'bleed demon'
<geist>
because it cuts you
<kazinsal>
an i5-7400 may not be much for modern edge-pushing stuff but it's still four cores at 3.something GHz
<Ermine>
geist: could you please show a photo?
<kazinsal>
reminds me once my big work project series is over I need to make a trip down to SEA
<kazinsal>
got about another month or so of progressive network replacement stuff
<kazinsal>
then I can finally get some time to do a run down to the emerald city
<geist>
hah not handy
<geist>
oh nice. if you remember giv eme enough warning and we can grab a beer
<kazinsal>
for sure
<kazinsal>
it's been ages since I've done the whole canadian tourist thing
<geist>
need a day or so in advance so i can plan on being in the city at the time
<geist>
since i dont commute in every day
<kazinsal>
woodland park, pike place, all that
<geist>
nice
<kazinsal>
I'd like to do a saturday-sunday thing because the connections museum is only open on sundays these days
<kazinsal>
and I'd love to hit them up and do the whole tour of a crossbar switch
heat has joined #osdev
<kazinsal>
iirc they've got a T1 hooked up through some deplexers to a 1920s phone switch
<geist>
oh yweah i've been wanting to go there too!
<geist>
mahybe get the whole crew, sarah,e tc
<kazinsal>
yeah!
<kazinsal>
I come from a long line of phone guys
<geist>
what a highly specific museum with such depth
<kazinsal>
so that kind of thing is in my blood haha
<geist>
i've been meaning to go since i discovered the channel, but they're open only on sundays or something
<kazinsal>
yeah, it's a super narrow window
<geist>
too bad the living computer museum has never come back
<kazinsal>
so I'm thinking this fall after all my work obligations are sorted I'll find a good weekend to drive down
<geist>
i'm still really sad about that. i used to visit like once a month or so
<kazinsal>
drive down a friday night, spend two nights in seattle
<kazinsal>
drive back home the sunday evening
<kazinsal>
it's just the timing and scheduling it around work that's the pain
<kazinsal>
I'm midway through a massive restructuring for a strategic customer so mid-late october is my earliest
<kazinsal>
so probably once we start seeing our regular PNW grey and wet weather I can do a trip down
<geist>
yeah the rain is starting tomorrow
<kazinsal>
yeah, the grey is starting to roll in here
<kazinsal>
I can see it in the distance beyond the mountains northwards
<kazinsal>
I'll figure out what my mid long term schedule this fall looks like as far as being able to do a long weekend in SEA looks like -- if we can make a specific timeframe work maybe we can get sortie out in the same timeframe and do an impromptu PNW osdev meetup
<kazinsal>
pull a "oh yeah, it's definitely a work relevant thing" and get some folks out for a weekend
<kazinsal>
from my end it's just a case of knowing in advance what the timeline looks like for a trip down to the lower 48 -- I've got a nexus card so CBP just waves me through
grumbler has quit [Quit: It's time]
<kof123>
yes yes, the northern hemisphere is entering the autumn underworld lol https://www.youtube.com/watch?v=l6DOGITIfAY ♎ i humbly suggest leopard and spotted cow dancing/costumes + drinks + sparklers lol "the grey is starting to roll in here" "what the timeline looks like for a trip down" the dragon of darkness rules for 6 months, you have 6 months
<bslsk05>
'Bucks Fizz - The Land of Make Believe (Official Video)' by BucksFizzVEVO (00:03:51)
<kof123>
TLDR: be glad i don't have money to attend such a meetup lol
<kazinsal>
it'd be great to roll up a proper osdev PNW meetup at one of the local seattle computing museums
gog has joined #osdev
<Ermine>
So, CONFIG_LRU_GEN=y, but I've still got machine hang when it run out of memory :(
<Ermine>
gog: may I pet you
<gog>
hi
<gog>
yes
* Ermine
pets gog
flom84 has quit [Quit: Leaving]
* gog
prr
tixlegeek has quit [Quit: tixlegeek]
tixlegeek has joined #osdev
<sortie>
kazinsal, headed to Denver on Friday for a week :) Though already booked the trip and currently we don't quite have the travel budget for normal office visits like the olden days :(
<sortie>
I miss SEA
<kof123>
i'll be good, however there is a limited window for jokes. > kof, your metaphors are all great, but how does that help with osdev? simple, only the magical sparkling lambda salamander (see cover of sicp book) can defeat the evil penguin king https://www.youtube.com/watch?v=xlEmUF3kWhA
<bslsk05>
'Little Nemo - The Dream Master Stage 8: Nightmare Land (Part 1)' by BeanyOne (00:01:51)
zxrom has quit [Ping timeout: 264 seconds]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 264 seconds]
Brnocrist has quit [Ping timeout: 244 seconds]
tixlegeek has quit [Quit: tixlegeek]
CaCode- has quit [Quit: Leaving]
xenos1984 has quit [Read error: Connection reset by peer]
netbsduser` has joined #osdev
zxrom has joined #osdev
xenos1984 has joined #osdev
cloudowind has quit [Quit: Lost terminal]
Cindy is now known as bnchs
bnchs is now known as Cindy
netbsduser` has quit [Ping timeout: 260 seconds]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
netbsduser` has joined #osdev
<zid>
heat which BSD variant do I buy if I need >4GB of ram
<heat_>
windows
<heat_>
that's my favourite BSD variant at least
heat_ has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
Brnocrist has joined #osdev
Burgundy has joined #osdev
<zid>
windows doesn't do >4GB of ram unless you buy the special datacenter version
<Cindy>
>artifical limits
<Cindy>
oh microsoft
<Cindy>
never change
<ripsquid>
Is there anything I need to keep in mind when setting up interrupts? Any specific addresses that needs to be aligned or something. I am having issues (might be rust related but just wanted to make sure I didn't miss anything)
<heat_>
ripsquid, what arch
<heat_>
wdym "setting up interrupts"
<ripsquid>
x86_64. I am trying to setup the idt and also its descriptor
<zid>
x86 surprisingly doesn't really give a shit about the *dt tables being aligned for some reason afaik?
<ripsquid>
I am also having a difficult time googling what the "0008:" means in this log from qemu? "IP=0008:0000000000113910"
<zid>
cs
<zid>
like jmp 0x8:0x113910
<zid>
x86 has had segmentation for.. a while
<ripsquid>
Okay. That is what I thought but wanted to make sure.
<zid>
If you post the qemu interrupt logs and stuff we can figure it out for you
<zid>
or you can keep poking at it and ask questions if you get stuck
<ripsquid>
The address that qemu calls when trying to "run" an interrupt is not the same address i put into the IDT. I think that is why it's double faulting. I'll keep poking and if I need any help, I'll ask.
<zid>
also I think the IDT= line actually shows the IDTR
<ripsquid>
yes it does
<zid>
so that x doesn't do what you want
<ripsquid>
no it shows the location of idt.
<zid>
does it? that's not how the GDT= one works
<zid>
GDT= definitely shows the GDTR
<ripsquid>
i am doing secondary logging to the screen and that shows the address of both idt descriptor and idt. And that address is the one of the idt
<zid>
well it doesn't match your ip=
<zid>
lowest two bytes of an idt entry are lowest two bytes of the linear address afaik
<zid>
then selector, which is.. 0
<zid>
but this would work fine as an IDTR
<zid>
3808 bytes at 0x8f000000 or something, endian is hard
<zid>
I'd have to check in the manual for how it's padded
<zid>
oh no I don't, it's packed, u16 limit, u64 linear
<ripsquid>
IDT= 0000000000154100 00000fff The first part is the location of the IDT and the second part is the size
<zid>
okay then your idt 0 entry makes 0 sense
<zid>
definitely when compared to the fault addr
<zid>
oh but is that the double fualt, or the interrupt?
<zid>
that could make sense as the double fault addr
elastic_dog has quit [Ping timeout: 240 seconds]
<zid>
You cut the interesting line off that tells you what the fault is
<zid>
old 0xe, new 0xd
<zid>
or whatever
<ripsquid>
check_exception old: 0xffffffff new 0xd
<ripsquid>
might be because i called an exception with int 0
<zid>
yea, #Gp
<zid>
rip=112e73, fault address 112e73
<zid>
I'd suggest that this ran code for a bit before actually crashing
<zid>
and isn't trying to deliver an int 0 at all
<zid>
x /i that memory region?
<ripsquid>
What should run some code before crashing?
<zid>
The cpu, has done
<zid>
this isn't deliver interrupt -> crash
<zid>
this is "i am already running code at 0x112e72, then crash trying to run 0x112e73"
<zid>
it eats a #GP from fetching a naughty instruction by the looks of it, not double faulting from trying to deliver an interrupt to a broken handler
<ripsquid>
0x00112e72: ff cd . .
<zid>
i gives instructions afaik
<ripsquid>
my screen debugging is saying that the exception handler should be at address 0x110EE0
<zid>
not sure what the alignment should be though, it might resyncronize if you go back far enough, but there's *definitely* something there though
<zid>
try from ee0, looks like it's working fine but crashing inside it
<zid>
after running off the end or something
<ripsquid>
0x00110ee0: 55 . .
<zid>
yea that's push ebp
<zid>
breakpoint it?
<zid>
bet it works fine
<ripsquid>
huh?
<zid>
your crash isn't on delivering interrupts, it's hitting it, running a bunch of code, then faulting
<zid>
imo
<zid>
hence the #Gp at 11... + offset
<zid>
not at the interrupt entry
<ripsquid>
shouldn't that first IP point to the beginning of the exception handler?
<sham1>
Not unless the fault comes from inside the exception handler
<zid>
If it were crashing at the interrupt handler, it would
<zid>
it does not, so it seemingly isn't
<zid>
it's crashing in some random code that the interrupt code contains
<ripsquid>
the first interrupt is planned from my end. I can send a pastebin with the rest of the following interrupts happening after it
<zid>
it is a fault *not at your exception handler's address*
<zid>
so the case of the fault was *not* a jump to your exception handler.
<zid>
It was just a crash.
<ripsquid>
as soon as I am done setting up interrupts I am calling "int 0". Shouldn't that at least go to my interrupt handler?
<zid>
are you getting to the int 0?
<zid>
I suggested you breakpointed it
<zid>
because this crash looks unrelated to your int 0
<ripsquid>
Still not sure how I would breakpoint it.. But the printing done to the screen right above int 0 did happen. And there isn't much code after int 0 either. Essentially just returning out of the function and infinite while loop
<ripsquid>
If I remove my int 0 nothing happens. It just runs the infinite loop. Only if i add it back I get an exception
<zid>
with gdb
<zid>
run qemu with -s -S
<zid>
run gdb, target remote localhost:1234
<zid>
break *0x1100ee0 or whatever it was
<zid>
file kernel.bin for symbols
<PapaFrog>
On amd64, is it possible to have a mix of 32bit and 64bit descriptors in the GDT? Use the 32bit descriptors in protected mode and use the 64bit ones in long mode?
<PapaFrog>
I don't see anything in the SDM that says it shouldn't be possible.
<Mutabah>
It's possible, and commonly done
<Mutabah>
for exactly that - running 32-bit code with a LMode kernel
<PapaFrog>
Thank you.
<ripsquid>
hmm. Got something else when setting a breakpoint and continuing with gdb
<ripsquid>
Program received signal SIGQUIT, Quit.
<ripsquid>
0x0000000000112b63 in rust_start ()
nur has quit [Read error: Connection reset by peer]
<ripsquid>
No breakpoint hit either
<zid>
which confirms what we thought
<zid>
what's... at 112b63 in rust_start? idk if you can addr2line for rust
sortie has quit [Quit: Leaving]
sortie has joined #osdev
<heat_>
yeah rust gens DWARF im pretty sure
<heat_>
gdb works on rust as well AFAIK
<zid>
rust had a gcc frontend for a while afaik?
grumbler has joined #osdev
<nikolar>
gcc rust is an active project
FreeFull has joined #osdev
heat_ has quit [Read error: Connection reset by peer]
heat has joined #osdev
elastic_dog has quit [Ping timeout: 264 seconds]
elastic_dog has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
<mcrod>
hi
Ram-Z has quit [Ping timeout: 252 seconds]
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
Ram-Z has joined #osdev
<sham1>
hi
<heat>
dragonflybsd
gxt has quit [Ping timeout: 252 seconds]
gabi-250 has quit [Ping timeout: 252 seconds]
gxt has joined #osdev
gabi-250 has joined #osdev
xenos1984 has quit [Ping timeout: 240 seconds]
freakazoid332 has quit [Ping timeout: 258 seconds]
xenos1984 has joined #osdev
elastic_dog has quit [Ping timeout: 258 seconds]
elastic_dog has joined #osdev
ExclamationPoint has quit [Remote host closed the connection]
Arthuria has joined #osdev
Arthuria has quit [Ping timeout: 240 seconds]
Arthuria has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
goliath has joined #osdev
frkzoid has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<geist>
hiya
<gog>
hi
<gog>
hihihihih
<Ermine>
hi gog, may I pet you
<heat>
hi geist and gog
<heat>
G&G
<geist>
why hello there heat
<geist>
and gog, and ermine
<Ermine>
hi geist
<heat>
i'm doing really shit accounting using google sheets
<heat>
because excel is too expensive and also LINOX KERNAL
<geist>
that's what i do
<geist>
works fine, as loing as you're okay with it being on the cloud, etc etc
<heat>
i love THE CLOUD
<heat>
as long as it's AI ACCELERATED
<heat>
google's browser office suite is actually really great and beats using libreoffice by a wide margin
<heat>
i've heard the apple macOS office stuff is actually pretty great too but I can't speak from experience
<geist>
yeah i suspect that pretty much all office suites are at least totally sufficient for basic stuff
<heat>
compatibility is complicated though
<geist>
but being not a power user i have no idea where they individually fall apart in advanced stuff
<heat>
and UX clunkyness
<geist>
yah i assume the browser based things fall over first from a scalability point of view, i just dont know where that is
<Ermine>
powerpoint online hangs on linux from time to time :(
<heat>
>scalability
<heat>
did mjg /nick over to geist
<geist>
PESSIMAL
<heat>
GOOGLE SHEETS PESSIMAL WEBDEV JAVASCRIPT
<geist>
qemu 8.1.1
<heat>
is it interesting?
<geist>
oh i dunno, vs 8.1.0 i assume just a handful of bugfixes. lemme see
<geist>
was just syncing the repo
<Ermine>
google sheets might be pessimal, but it's ok when compared to pessimality of libreoffice
<heat>
do you need to build it or is it just a pride thing? lol
<Ermine>
?
<sortie>
Awww the gang is here
<geist>
heat: qemu? i always like to run the latest one yeah
<geist>
especially with riscv stuff
<sortie>
heat, I am making terrifying progress on my FAT driver
<geist>
seems like about 1/3 of the delta between 8.1.0 and 8.1.1 are riscv fixes
<geist>
though nothing that really sticks out
<sortie>
heat, a quick hackathon and boom I got read-only support for FAT12/16/32 and I can now mount the /boot/efi I made natively with mformat(1) :)
<netbsduser``>
i still know very little about fat
<netbsduser``>
other than that they used linked lists for some reason. bizarre filesystem
<sortie>
I just gotta whip up O_CREAT (+ mkdir), pwrite, and truncate and then I should be able to place EFI/BOOT/BOOTX64.EFI natively
<geist>
not much to know, designed to work well for 8 bit cpus
<netbsduser``>
the osdev wiki cautions somewhere that "if you design your own filesystem, it will be FAT!" but i think that would take genuine talent
<sortie>
netbsduser``, the things I do know are things that makes me curse the name of Bill Gates, god rest his soul
<geist>
yah it gets super clunky in the dir name stuff, once you get out of 8.3 territory, but that was a bodge on top of an old design, so kinda makes sense
<geist>
otherwise t's just very very simple, actually fairly standard for simple 8/16 bit fs designs in late 70s early 80s
<geist>
if you look at things like prodos, apple 3.3, CP/M, etc they were generally fairly similar
<Ermine>
What if ESP was ext[2-4] all this time
<geist>
and a bit more sophsticated than some simply because i *can* deal with non contiguous files. a common strategy fses on machines at the tme did was not even have a FAT: the dir entry simply has a start + length field
<geist>
and files have to be contiguous
<netbsduser``>
what i do know is that the windows "fastfat" driver couldn't just cache the metadata blocks, like is done for efficiency's sake in UFS and family. instead they generate an abstract representation of it and cache that
<sortie>
geist, you know one particular property that I've really really come to appreciate: Files having an identity and being able to look up their metadata based on that identity in constant time.
<netbsduser``>
geist: i am simply too used to the unix filesystem tradition, i think
<heat>
sortie, terrifying is a great adjective for a FAT driver :D
<sortie>
My whole filesystem implementation is reallyyyyy dependent on that property. E.g. for ext2, it's just the inode number, boom I can look that up in a table and there is the metadata
<geist>
sortie: on FAT? yeah. makes sense: in something like DOS you can have say 8 open file handles (FILES=8) preallocated, and all the metadata to do everything with that file can be stored in some sort of fixed block of ram. say 64 bytes, dunno
<geist>
since the only real metadata you have to hold at least a pointer to is the location of the FAT on the disk, since it serves multiple purposes
<sortie>
It all breaks down terrifyingly on FAT. There's no file number. You could use the directory entry, but it may be moved (such as on a rename to another directory). You could use the first cluster, but now you can't look up the metadata.
<geist>
i think in DOS it wasn't so much that there was a FS driver or a 'mount' or any sort of shared metdata, it simply found the FAT and then stored a pointer to it
<sortie>
FAT is all based about a concept of having state in the file handle about how you got there
<netbsduser``>
i heard somewhere that there is identity of dirent and i-node in fat
<sortie>
netbsduser``, FAT has dirents sure, but no inode
<geist>
yeah but that's beause you're approaching it from a unix inode point of view. it doesn't map to the notion that there's a single number that identifies it
<geist>
exactly, the file handle holds the state, the path is how you got there in FAT, and in general dos/windows itself
<sortie>
Yeah. It's just, really deeply embedded in my system. Each filesystem object is a (device, inode) pair uniquely.
<netbsduser``>
this all make me curious about the technical challenge i'd face in implementing a FAT driver for my kernel, it sounds utterly hostile to my vfs
<geist>
totally. it's a common problem. so i remember in the beos fat driver, for example, it would concoct an inode number based on the offset of the dirent that you found it
<geist>
and then if you moved the dirent (rename, etc) it would start to build up a hash table of translations
<sortie>
So the way I made it work was to use the first cluster as the inode number on FAT, and then keep the state of where the directory entry is inside the in-memory Inode object. It's ref counted on use anyway so that kinda works
<geist>
and so over time if you mounted a fs and really moved things around the in memory usage would go up
<geist>
but if you unmounted, remounted, it would start from scratch. so inode numbers weren't consistent between mounts
<sortie>
Picking the first cluster, though, does give me consistency but doesn't let me defrag the first cluster at runtime
<sortie>
I had the very same problem with ISO 9660 but much easier since it's read-only, so I used the dirent as the inode number and it contains all the metadata
<geist>
iirc the vnode number was somehting like {32:32} {cluster of the dirent:offset within the dirent} or something like that
<geist>
so you could jump directly to the dir entry, but then had to not move dirs around
<sortie>
The good news is that I don't give a damn about FAT being very efficient. Let it fragment all to hell and suck as long as it works correctly enough. I really just need to place BOOT/EFI/BOOTX64.EFI. I'm honestly considering not doing long file names.
<geist>
yah i think the beos driver also pulled the fat chain into memory for a file and built an in-core linked list of it
<netbsduser``>
it's unfortunate that the uefi standardisers didn't opt for a conventional filesystem
<geist>
but yeah with moderate block caching you can generally get around the inefficiencies of having to go to the FAT over and over again
<geist>
hey it could have been worse: UDF
<sortie>
I mean... FAT is kinda an okay choice?? Like anything else from the proprietary world would've been worse
<geist>
for a whiel in the mid 2000s UDF was going to be The Defacto FS for transferring between things
<geist>
talk about a design by committee. i actually *went* to that committe meeting a few times when i worked at apple
<sortie>
ext2 is probably the only thing that would've been a good choice for the open source world in terms of simplicity
<geist>
UDF has all of these extra layers of implementation that actually let you mount and run it on a real block device, journalling (was planned i think) and it was just as bad as iso9660 + fat combined
<geist>
with utf16, case insensitivity, etc
<netbsduser``>
i know udf allegedly permits writing, but i pretend i never heard that
<geist>
yah i remember actually formatting a 4GB disk and putting source on it, etc
<heat>
netbsduser``, FAT is as conventional as you can get lol
<sortie>
geist, the cool thing is that I got an EFI-only laptop and it's got a Linux driver issue that makes it deadlock in graphics stuff after a few seconds, but it runs Sortix perfectly. Except I don't have an EFI implementation. So I recompiled GRUB natively with EFI support, it actually booted, and then I used mtool's mformat(1) to make an EFI system partition, taught my disked to set up the UUID in the GPT, and then used mcopy(1) to place the
<sortie>
bootloader in the ESP. And it worked!
<heat>
what other option was there?
<heat>
one of the random variant of UFS/FFS? EXT2?
<geist>
actually iirc netbsd curiously has the most complete UDF implementation for some reason
<heat>
surely *not* NTFS?
<geist>
or did at some point
<sortie>
So now I'm writing a FAT driver natively on my Sortix EFI laptop to bridge the gap so I can use grub-install directly without mtools fakery
<netbsduser``>
heat: something with a block bitmap, inodes containing direct/indirect/doubly-indirect block pointers, and dirents
<geist>
hey at least msft didn't inflict NTFS on everyone. they've been pretty hard core about not making NTFS be some sort of defacto solution for anything but themselves
<geist>
not that NTFS is a bad design, but i'd say it's at least an order of magnitude more complex than FAT
<sortie>
I imagine how terrifying it would be with a bunch of rogue NTFS drivers that go writing
<heat>
netbsduser``, sounds pretty niche to me
<sortie>
Good thing they didn't do that
<geist>
exactly. though i've also heard by folks that worked on the NT kernel team that the NTFS.sys driver is completely terrifying
<heat>
firmware already has issues writing on FAT filesystems
<heat>
due to downstream bugs
<geist>
one of those solid but completely incomprehensible piles of code that no one wants to touch but is so essential
<heat>
it's why apple refused to implement write support in the APFS EFI driver
<netbsduser``>
heat: it's the norm and it's simple enough, and it doesn't spit on the norms of unix-like VFSes
<sortie>
heat, I am curious what bugs they are
<netbsduser``>
unfortunately now that fat has been discussed i feel the urge to implement a driver for it
<heat>
FAT is much more of a norm than <insert random unix filesystem in the early 00s>
<gog>
i'm webdev
<gog>
:(
<heat>
in fact it's pretty likely the relevant OSes already had a FAT driver when EFI introduced it
<netbsduser``>
i suspect it will be significantly more challenging than fuse, 9p, ufs, and ext2 were, based on what i hear here
<geist>
yah i was working on a FAT driver for LK that i need to brush off and drag over the last 20%
<heat>
sortie, gosh, i don't know, but write support is always tricky, and firmware people can't be trusted (much less the downstream ones...)
<geist>
netbsduser``: FAT? nah. we're complaining that its *dumb*
<geist>
but it's fairly simple
<sortie>
What stuff is using Universal Disk Format (UDF)?
<heat>
so historically there have been lots of problems writing
<heat>
hence apple discarding that idea outright
<geist>
sortie: DVDs and i think bluerays
<heat>
i did too, ext4dxe has no write support (and i was pretty strongly advised *against* adding write support)
<netbsduser``>
i am going to go investigate it immediately and start sketching out a driver
<geist>
it's something like iso13346
<sortie>
Right, so if I gotta play a DVD; I need a UDF driver to point it, and then whatever DRM bullshit to decode the files?
<geist>
basically UDF is the sucessor to iso9660. and had a lot more features for packet writing and whatnot
<geist>
but then most of the packet writing stuff no one cares about anymore, so i think it just endsu p being a more powerful iso9660
<geist>
but it also has the property of iso9660 that the superblock doesn't have to be in a particular spot, so it can be part of a hybrid disk where you have multiple fses overlaying each other
<heat>
EL TORITO
<geist>
so honestly i dunno if modern DVDs have both 9660 and 13346 at the same time
<geist>
anyway, yeah i think in practice it's just used for read only stuff, but it has all these additional layers
<geist>
when i briefly worked on the FS team at apple in 2005 my job was to literally work on the UDF driver which was in progress at the time
<geist>
but got pulled off to work on iphone after a few months
<heat>
iPoggers
<geist>
also 2005 was just about when the HDDVD and bluray wars were happening, so there was all this promise from both sides that the next gen discs were going to be the future for everything
<heat>
boy that UDF compatibility section sure is... fun
<geist>
so there was all this discussion about how packet writing and whatnot was going to revolutionize stuff because 50GB! omg that was an insane amount of space
<heat>
for onyx i pledge compatibility with the WALL-E DVD
<geist>
and then i thik apple and msft broke off comms about then and that's why the last revision was 2.6 about 2005. i think i may have gone to literally the last UDF committe meeting (the sheraton in san bruno in bay area, iirc)
* sortie
laughs in netflix and existing investments in dvd tech
<geist>
msft/toshiba was team hddvd, and sony/apply was team blu-ray
<geist>
you could feel the tension in the room. you were worried it was all going to turn into fisticuffs at any moment
<netbsduser``>
i remember having an hd-dvd player
<geist>
and both toshiba and sony had ninjas circling the room
<netbsduser``>
i haven't really got much of either
<netbsduser``>
i do have The Prisoner on bluray
<heat>
and then everyone held hands and took out a banner saying "gracias youtube"
<heat>
and everyone lived happily ever after
<geist>
i do remember eventually buying a bluray burner, i have it around here somewhere, but i dont think i ever burned at disc
<geist>
at the time they were pricey disks and then by the time they were cheap hard drives were already dwarfing 50GB so it didn't really matter
<heat>
the only likely working DVD player/tray I have is my old xbox 360
<heat>
if only I had a PS3, i could have a blu-ray player too
<geist>
i still have a pile of dvd readers that i sometimes use to bootstrap old machines or whatnot
xenos1984 has quit [Read error: Connection reset by peer]
<geist>
but those were simply old cdrom and dvd drives from old computers over the years that i've replaced but removed the useful guts to
<netbsduser``>
nowadays some computer cases seem to be completely missing 5.25" bays
<geist>
and modern machines there's not really any space to put them, yeah
<geist>
or you could, but that space is better used by a radiator or fans
<heat>
the XENON makes for a great movie player i swear
<heat>
powerpc >> x86
<heat>
x86? more like xeightycrap
<geist>
i remember endian was a bit deal with UDF too. i forget, it might support both endians
<geist>
thankfully DEC wasn't around then to force mid-endian on everyone
<sortie>
I have been recommending just skipping FAT as your first filesystem and going straight to ext2. It's surprisingly easy to implement ext2 reading and teaches you all the right concepts and ways to think. Meanwhile FAT will just teach you so many weird things that you kinda have to unlearn. But by doing FAT later, I did have to kinda retrofit FAT into a modern model that it doesn't fit into, but I'm okay enough with that.
<geist>
yah also depends on if you intend to interact with removable media at all
<sortie>
I don't need FAT more than a Key-Value store for EFI (name -> bootloader)
<netbsduser``>
sortie: yes, it never even occurred to me to try fat, and now it looks like it's going to be annoying to fit into my vfs
<geist>
if you do then fat and possible exfat are mandatory, eventually
<netbsduser``>
whereas ext2 is just ufs without fragments and they call cylinder groups something else i think
<heat>
block groups
<sortie>
Jusssssttt reformat to ext2 :3 but yeah removable stuff is a common use case where the filesystem is outside of your control
<heat>
you also need to specify which kind of the 200 UFS variants you're talking about
<heat>
"yeah it supports UFS" means nothing
<netbsduser``>
fortunately my kernel doesn't yet have the capacity to deal with removed devices so the point is moot for me
<netbsduser``>
heat: at least netbsd's FFSv2 is coidentical with FreeBSD's FFSv2, so those are fair targets
<heat>
zfs on flash drives when
goliath has quit [Quit: SIGSEGV]
<netbsduser``>
come to think of it i don't even really *need* a fat driver
<netbsduser``>
i have fuse, for goodness sake
<geist>
huh well interesting, actually am formatting a SD card as UDF on windows 11
<geist>
seems to just work, just have to use the command line
<netbsduser``>
someone probably invented a fuse fat driver by now
<heat>
oh absolutely
<heat>
there are even fuse APFS drivers
bauen1 has joined #osdev
xenos1984 has joined #osdev
<mcrod>
one of you nerds might know
<mcrod>
is there a way in git to say "before git tag actually makes a tag, run this script first"
<mcrod>
the idea being, you can't create a tag until the script checks shit out
cloudowind has joined #osdev
FreeFull has quit []
<heat>
shut up nerd
Arthuria has quit [Ping timeout: 246 seconds]
heat has quit [Remote host closed the connection]
Turn_Left has quit [Read error: Connection reset by peer]
<geist>
hmm, probably a pre-tag hook?
<geist>
i'd look through what the various hooks are
heat has joined #osdev
<mcrod>
heat: :(
* cloudowind
greets everyone
<sortie>
heat, and boom, FAT truncate(2).
<sortie>
Means it can now write to the FAT, has logic for allocations, even keeps the fsinfo up to date so the next cluster pointer & free counts are maintained for the next mount
<sortie>
With those fundamentals, I can now move onto FAT pwrite
<sortie>
That'll teach you to question my ability to hack up a proper writing filesystem driver easily
<sortie>
:D :P
<sortie>
It's very fun to assume that the FAT filesystem is perfectly well formed and consistent and that my driver will always maintain those properties
<sortie>
Because any dirty unmount is gonna get nasttyyyy
<sortie>
Oh your FAT has an infinite loop?
<sortie>
Well that is going to be a LONG directory listing
Burgundy has quit [Ping timeout: 240 seconds]
<geist>
yah extending a file in fat is fun too since no sparse files you have to zero fill everything
<gog>
hi
vinleod has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vinleod is now known as vdamewood
vdamewood has quit [Quit: Life beckons]
<heat>
gosh fat sounds horrendous
<heat>
thats only future heat's problem
<heat>
and fuck that guy haha
<kazinsal>
it's very much a "let's just keep writing extension modules to the existing filesystem code" fs, yeah
<kazinsal>
like, 90% of the logic for fat12 works for fat16 and fat32
<kazinsal>
and fat12 was just fat8 with four extra bits attached
<heat>
but ext2/3/4 and ufs and shit are all "let's just keep writing extension modules to the existing filesystem code"
<heat>
and they didn't turn out horribly
<kazinsal>
yeah, but unix filesystems were designed originally for real machines
<kazinsal>
fat was designed originally for an 8-bit data entry terminal
<heat>
but you're not running a PDP-11 and neither am I
<heat>
you're running a VAX, with double the bits!
<kazinsal>
and that pdp-11 was double the bits of the 8080 that fat was originally implemented on
<kazinsal>
it was literally a "hack it together and ship it" solution to the problem of "how do files"
<kazinsal>
though the history is a fuck because the operating system that originally implemented FAT8 never actually got released