klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
jeaye has quit [Quit: WeeChat 3.7.1]
jeaye has joined #osdev
\Test_User has joined #osdev
Hammdist has joined #osdev
Hammdist has quit [Quit: Client closed]
stolen has joined #osdev
rorx has quit [Ping timeout: 264 seconds]
\Test_User has quit [Read error: Connection reset by peer]
\Test_User has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
netbsduser`` has quit [Ping timeout: 255 seconds]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
netbsduser`` has joined #osdev
netbsduser`` has quit [Ping timeout: 246 seconds]
netbsduser`` has joined #osdev
netbsduser`` has quit [Ping timeout: 260 seconds]
Arthuria has joined #osdev
rorx has joined #osdev
Arthuria has quit [Ping timeout: 246 seconds]
pg12 has quit [Ping timeout: 255 seconds]
netbsduser`` has joined #osdev
pg12 has joined #osdev
netbsduser`` has quit [Ping timeout: 246 seconds]
stolen has quit [Quit: Connection closed for inactivity]
goliath has joined #osdev
pg12 has quit [Ping timeout: 248 seconds]
pg12 has joined #osdev
netbsduser`` has joined #osdev
netbsduser`` has quit [Ping timeout: 255 seconds]
elastic_dog has quit [Ping timeout: 255 seconds]
elastic_dog has joined #osdev
zxrom has quit [Ping timeout: 240 seconds]
danilogondolfo has joined #osdev
<zid> oof, couldn't have picked a worse place to dig that hole, horrendous plant roots, then apparently someone's spoil pile for broken bricks, then a tree root
Burgundy has joined #osdev
stolen has joined #osdev
Left_Turn has joined #osdev
GeDaMo has joined #osdev
nyah has joined #osdev
[itchyjunk] has joined #osdev
gog has joined #osdev
zxrom has joined #osdev
bauen1 has quit [Ping timeout: 258 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
<mcrod> you’re a gardener?
<gog> no this is patrick
<mcrod> gog my back hurts
jimbzy has quit [Ping timeout: 255 seconds]
<gog> mine too
<sham1> mcrod: have you tried being angry at your back?
<mcrod> no
<mcrod> i’m not angry
<mcrod> but it feels annoying
<GeDaMo> Do you spend a lot of time sitting?
jimbzy has joined #osdev
<zid> mcrod: no, cats--
<zid> holes++
xenos1984 has joined #osdev
pg12 has quit [Ping timeout: 258 seconds]
pg12 has joined #osdev
pg12 has quit [Ping timeout: 244 seconds]
pg12 has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
gog` has joined #osdev
bas1l has joined #osdev
tom5760_ has joined #osdev
tommybomb_ has joined #osdev
geist_ has joined #osdev
staceee_ has joined #osdev
yuiyukihira_ has joined #osdev
jleightcap_ has joined #osdev
noeontheend_ has joined #osdev
Benjojo_ has joined #osdev
whereiseveryone_ has joined #osdev
alecjonathon_ has joined #osdev
sm2n_ has joined #osdev
gjn_ has joined #osdev
patwid_ has joined #osdev
ddevault_ has joined #osdev
exec64_ has joined #osdev
vismie_ has joined #osdev
pitust_ has joined #osdev
torresjrjr__ has joined #osdev
asymptotically_ has joined #osdev
yyp_ has joined #osdev
rselim_ has joined #osdev
alethkit_ has joined #osdev
geist has quit [*.net *.split]
Benjojo has quit [*.net *.split]
basil has quit [*.net *.split]
tom5760 has quit [*.net *.split]
noeontheend has quit [*.net *.split]
ddevault has quit [*.net *.split]
alethkit has quit [*.net *.split]
rselim has quit [*.net *.split]
patwid has quit [*.net *.split]
vismie has quit [*.net *.split]
lh has quit [*.net *.split]
exec64 has quit [*.net *.split]
yyp has quit [*.net *.split]
gjn has quit [*.net *.split]
tommybomb has quit [*.net *.split]
pitust has quit [*.net *.split]
asymptotically has quit [*.net *.split]
whereiseveryone has quit [*.net *.split]
yuiyukihira has quit [*.net *.split]
alecjonathon has quit [*.net *.split]
jleightcap has quit [*.net *.split]
sm2n has quit [*.net *.split]
staceee has quit [*.net *.split]
sham1 has quit [*.net *.split]
torresjrjr__ is now known as torresjrjr
geist_ is now known as geist
Benjojo_ is now known as Benjojo
tom5760_ is now known as tom5760
alethkit_ is now known as alethkit
patwid_ is now known as patwid
rselim_ is now known as rselim
vismie_ is now known as vismie
exec64_ is now known as exec64
noeontheend_ is now known as noeontheend
yyp_ is now known as yyp
tommybomb_ is now known as tommybomb
asymptotically_ is now known as asymptotically
pitust_ is now known as pitust
whereiseveryone_ is now known as whereiseveryone
alecjonathon_ is now known as alecjonathon
jleightcap_ is now known as jleightcap
yuiyukihira_ is now known as yuiyukihira
gjn_ is now known as gjn
sm2n_ is now known as sm2n
staceee_ is now known as staceee
jleightcap has quit [Read error: Connection reset by peer]
patwid has quit [Write error: Connection reset by peer]
alethkit has quit [Read error: Connection reset by peer]
whereiseveryone has quit [Write error: Connection reset by peer]
sm2n has quit [Write error: Connection reset by peer]
asymptotically has quit [Write error: Connection reset by peer]
exec64 has quit [Write error: Connection reset by peer]
yuiyukihira has quit [Write error: Connection reset by peer]
noeontheend has quit [Read error: Connection reset by peer]
pitust has quit [Read error: Connection reset by peer]
gjn has quit [Write error: Connection reset by peer]
alecjonathon has quit [Read error: Connection reset by peer]
ddevault_ has quit [Write error: Connection reset by peer]
rselim has quit [Write error: Connection reset by peer]
vismie has quit [Write error: Connection reset by peer]
staceee has quit [Write error: Connection reset by peer]
tommybomb has quit [Write error: Connection reset by peer]
tom5760 has quit [Read error: Connection reset by peer]
yyp has quit [Write error: Connection reset by peer]
listentolist has joined #osdev
pitust has joined #osdev
gjn has joined #osdev
patwid has joined #osdev
ddevault has joined #osdev
noeontheend has joined #osdev
sm2n has joined #osdev
alecjonathon has joined #osdev
tom5760 has joined #osdev
yuiyukihira has joined #osdev
tommybomb has joined #osdev
yyp has joined #osdev
jleightcap has joined #osdev
rselim has joined #osdev
whereiseveryone has joined #osdev
exec64 has joined #osdev
staceee has joined #osdev
asymptotically has joined #osdev
alethkit has joined #osdev
vismie has joined #osdev
lh has joined #osdev
sham1 has joined #osdev
pounce has quit [Ping timeout: 258 seconds]
pounce has joined #osdev
Left_Turn has quit [Quit: Leaving]
netbsduser`` has joined #osdev
<mcrod> GeDaMo: yes
<zid> I think the little pain I felt in my hand that let a mark while I was digging was like, a bee or something
<zid> my hand doesn't bend right
<zid> how quickly does lockjaw happen
<zid> and can you get it in your hands
<gog> might be wise to go get a DPT booster anyway heh
<zid> omg, do I hae diptheria too!?
<zid> I thought I just had tetanus
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
<zid> The symptoms of tetanus usually start around 4 to 21 days after infection. Most people get symptoms after about 10 days.
<zid> I think I am safe
rorx has quit [Ping timeout: 264 seconds]
bas1l is now known as basil
bauen1 has joined #osdev
edr has joined #osdev
zxrom has quit [Quit: Leaving]
heat has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
Burgundy has quit [Ping timeout: 240 seconds]
gog` has quit [Ping timeout: 240 seconds]
stolen has quit [Quit: Connection closed for inactivity]
gog` has joined #osdev
Arthuria has joined #osdev
Arthuria has quit [Ping timeout: 240 seconds]
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
rustyy has joined #osdev
[itchyjunk] has joined #osdev
goliath has quit [Quit: SIGSEGV]
Left_Turn has joined #osdev
stolen has joined #osdev
rorx has joined #osdev
bauen1 has quit [Ping timeout: 258 seconds]
Arthuria has joined #osdev
netbsduser`` has quit [Ping timeout: 248 seconds]
gorgonical has quit [Ping timeout: 258 seconds]
netbsduser`` has joined #osdev
Burgundy has joined #osdev
Arthuria has quit [Ping timeout: 252 seconds]
yoyofreeman has joined #osdev
leon_on9527 has joined #osdev
leon_on9527 has quit [Remote host closed the connection]
zxrom has joined #osdev
goliath has joined #osdev
[Kalisto] has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
<Ermine> gog: may I pet you
<gog> yes
<zid> I'm taking auditions for a new cat btw
<zid> You'll be ranked by Style, Control, Damage and Aggression
* Ermine pets gog
* gog prr
<gog> i've got cat class and i've got cat style
<bslsk05> ​'Stray Cats - Stray Cat Strut' by StrayCatsVEVO (00:03:15)
heat_ has quit [Read error: Connection reset by peer]
<zid> He has that classic 80s face
heat_ has joined #osdev
netbsduser`` has quit [Ping timeout: 240 seconds]
<zid> Everybody looked like that somehow, like they were printing them
<Ermine> .cat { action: prr }
<Ermine> gog: ^
<gog> yes cat is in my classList
<zid> I am a martial wizard
<zid> zid casts punch. You take 12 damage.
<gog> dang
<gog> i only have 2hp
<gog> i'm ded
* Ermine throws healing jellyfish at gog
* gog is resurrected, lives--
* moon-child gives gog an amulet of life saving
<zid> "oLS? *uses a wand of death twice*
<zid> waste of space amulet
Arthuria has joined #osdev
Arthuria has quit [Ping timeout: 245 seconds]
<mcrod> qt does funny things
<gog> i like qt
<mcrod> so do I
<mcrod> but tell me
<mcrod> if I have a QTimeEdit that has a minimum value of 00:15, then I increment with a custom stepBy() method by 15 minutes
<mcrod> why is it giving me 31 minutes
<mcrod> .
gog` has quit [Read error: Connection reset by peer]
gog` has joined #osdev
xenos1984 has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
netbsduser`` has joined #osdev
gog has quit [Quit: Konversation terminated!]
danilogondolfo has quit [Quit: Leaving]
xenos1984 has joined #osdev
gog` has quit [Ping timeout: 258 seconds]
<mcrod> never mind
<mcrod> turns out I can't read...
<heat_> i have linux
gog has joined #osdev
<zid> You can't fool me
<zid> that's about windows
<zid> I need a cat catalogue
<zid> catalogoglue
<jimbzy> catalogoguguele
<gog> hi
<jimbzy> Sup gog?
<gog> lotsa stuff
<jimbzy> Good stuff I hope.
<gog> actually yeh
<jimbzy> Noice
grumbler has joined #osdev
<jimbzy> I'm just enjoying a day off and messing around with my PCB layout.
<heat_> TIL "cast operator on the left hand side of an assignment" was ever a thing
<heat_> at least in some compilerz
<heat_> makes little sense?
<heat_> unsigned short a; (int) a = 10; /* the fuck happens here? */
Arthuria has joined #osdev
<nortti> I'd presume it does the same as (int)(a = 10)
Arthuria has quit [Ping timeout: 240 seconds]
<heat_> but that doesn't cast like you want it to
<heat_> i think the idea was like "struct s {struct sockaddr *in;}; struct s *p; (struct sockaddr_in *) (p->in) = in4;"
<heat_> something like this
<heat_> but i can't be sure and this doc is 30yo
<heat_> https://computernewb.com/~lily/files/Documents/NTDesignWorkbook/ this dir has a bunch of good docs on the original NT kernel
<bslsk05> ​computernewb.com: Index of /~lily/files/Documents/NTDesignWorkbook/
stolen has quit [Quit: Connection closed for inactivity]
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
[Kalisto] has quit [Read error: Connection reset by peer]
[Kalisto] has joined #osdev
rustyy has quit [Quit: leaving]
<sortie> heat_, so pwrite now works on FAT! Plus truncate(2) although there is some corruption going on when I expand a file a second time or something, probably a quick fix, gotta fix that
<sortie> It is quite magical when a read-only filesystem driver starts having write support and things like "echo foo > bar" starts working
<sortie> It'll be quite major when I add O_CREAT / mkdir
goliath has joined #osdev
foudfou has quit [Ping timeout: 252 seconds]
foudfou has joined #osdev
Arthuria has joined #osdev
Arthuria has quit [Ping timeout: 244 seconds]
grumbler has quit [Quit: It's time]
torresjrjr has quit [Remote host closed the connection]
heat_ has quit [Remote host closed the connection]
torresjrjr has joined #osdev
heat_ has joined #osdev
<geist> sortie: handling all the FAT12/16/32 variants? I found that to be kinda a pain
<geist> FAT12 in particular
<geist> and the 12/16 way the root dir is handled
<geist> not that it's difficult per se, but it requires you restructure some of your assumptions about things
<sortie> geist, yup, I was striken by grief when I realized 12 was not a divisor of 512
<geist> yuuuup
<sortie> So the FAT12 entry might cross a sector
<sortie> Anyway, to be honest? Eh it's easy enough
<netbsduser``> i have just been throwing together a fat driver as well, currently only as far as readdir'ing the root directory of a fat12/16
<sortie> I just wrote a ReadFAT / WriteFAT pair of functions that abstracts the encoding away
<geist> yay
<netbsduser``> and the fat12 fat entries that cross block boundaries are filthy, vile, rotten
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<geist> yah i think i made it harder for myself by writing some sort of ForEachCluster(callback) sort of routine
<geist> so it's fast, because it can walk through the FAT, holding the existing FAT sector open as it does
<sortie> The root directory thing is more annoying though
<geist> but then it is just more complicated
<sortie> It's not that hard to special case in readdir tho
<netbsduser``> the fixed root directory is an odd one
<netbsduser``> i have no idea why they decided to do it
<nortti> because originally that was the only directory
<sortie> I have an utility function for iterating through a file sector by sector in each cluster anyway, so just made it iterate the root dir instead
<geist> right, they added subdirs in DOS 2 or 3 iirc
<nortti> dos 2, alongside hard disk support
<geist> which probably added FAT16
<sortie> geist, but to be honest? The FAT12/16/32 differences are a small issue compared to just all the overall FAT issues. It's actually quite impressive how they all have the same feature set in practice
<netbsduser``> i deal with it by having the vnode extension representing the root directory be always in memory, it's tagged with a "this is the root directory", and the load-page vnode op simply deals appropriately with that flag
<geist> right, something like that
Turn_Left has joined #osdev
<nortti> < geist> which probably added FAT16 ← interestingly enough, seemingly not. that came with support for disks bigger than 20MiB in dos 3.0
<geist> interesting. i thought you could only push FAT12 to 4MB...
<geist> maybe that's just ony 4MB in a reasonable sized cluster
<geist> yeah.... 4K clusters, 1024 bytes. yeah makes sense
<geist> that's just the modern limit
<sortie> geist, the real fun challenge is taking FAT and making a good implementation of it that fits in well semantically in the world of much better filesystems and operating system primitives
<netbsduser``> i'm sure i heard a report of some poor user accidentally creating an HFS original volume on a 1tib drive
<sortie> Oh what's really fun is that FAT actually supports non-512 sector sizes quite explicitly
<geist> yah i have a slightly iffferent set of problems in LK because it's not vnode based, so the FAT driver itself has its own cache of vnodes and whatnot
<geist> for better or worse. i'm torn about adding a vnode based VFS to LK
<sortie> So you have have huge 4096 byte sectors * the largest cluster
<sortie> Although I think clusters are still limited to 32 KiB anyway
<geist> yep. i piddled with that in my unit tests
<netbsduser``> os x kindly set it up with 16mib blocks to let it fit with the 16-bit block pointers
<nortti> < sortie> Oh what's really fun is that FAT actually supports non-512 sector sizes quite explicitly ← and they are even used! e.g. the pc-9801 8" / 3.5" floppy format
<geist> 32KB except iirc early NT would let you format 64K clusters *but* windows 95 wouldn't read it
Left_Turn has quit [Ping timeout: 240 seconds]
<geist> i remember that actually being a real issue if you had like a 3GB drive and didn't want to use NTFS
<sortie> nortti, what is that sector size?
<nortti> 1024
<sortie> Oh cool
<geist> but just take a modern nvme, format it as 4K, put fat on it, you have the same thing
<geist> i haven't tried but i suspect you can tell qemu to use non 512 for nvme or whatnot
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
<netbsduser``> one thing i will say about fat, so far it's actually been less problematic to integrate its concepts with my vfs
<netbsduser``> and i do a close semblance of what is described in the sunos "vnodes" paper of 1985
<ChavGPT> where is the paper?
<ChavGPT> i'm curious if they had the arbitrary vnode limit
Arthuria has joined #osdev
<heat_> KERNAL
<heat_> sortie, glad to hear :)
Arthuria has quit [Ping timeout: 258 seconds]
elastic_dog has quit [Ping timeout: 255 seconds]
gog has quit [Quit: byee]
elastic_dog has joined #osdev
<sortie> Yay FAT truncate(2) works now, I had a bug where it didn't properly expand with another cluster if the last cluster was perfectly full
<ChavGPT> nortti: thank you
<heat_> ChavGPT, when's that obnoxious c-word mjg coming back
<ChavGPT> you may remember the word PESSIMAL was outlawed from previous usage
<Bitweasil> Hm. Odd question: ARMv8, the AT (address translation) instructions. If I use them to look up write permissions for a page, will that set the access flag? I don't think it should, because it's not an actual translation, but I can't find documentation one way or another.
<ChavGPT> so i think he retired
torresjrjr has quit [Remote host closed the connection]
torresjrjr has joined #osdev
<heat_> Bitweasil, geist might know
<heat_> but that's a really cute question isn't it lol
<heat_> i guess if it's allowed to cache it in the TLB the A bit is getting set anyway?
<geist> hmm, i think so
<geist> i know that's called out in exquisite detail somewhere, precisely when the A bit is set, but i'm fairly certain things like prefetching and whatnot *can* trigger it
<Bitweasil> I think I found the answer in one of the supplemental docs.
<heat_> yeah
<Bitweasil> > When hardware updates of the Access flag are enabled for a stage of translation an address translation instruction
<Bitweasil> that uses that stage of translation will not report that the address will give rise to an Access flag fault in the PAR,
<Bitweasil> and the result in PAR will be as if the value of the Access flag in the translation table entries for that address was 1
<Bitweasil> So, while prefetching and speculative stuff *can* set the AF, the AT instructions will pretend it's already 1.
<geist> because the HW mechanism is 'cpu goes to access page, finds TLB is missing, goes and walks the page table, hits a page entry with the bit not set, load entry and writes back'
<Bitweasil> Right.
<heat_> huh
<heat_> why do you care anyway?
<geist> correct. note that if your hardware doesn't have A bit writeback it might trigger a AF fault
<geist> but prefetching and speculation wont fire the AF unless the instruction is retired, i think
<Bitweasil> heat_, same reason I usually care about weird esoterica. :p
torresjrjr has quit [Remote host closed the connection]
<Bitweasil> Current task: Write an ARMv8 MMU. In C.
torresjrjr has joined #osdev
<Bitweasil> I do emulator dev currently.
<geist> so when hardware writes back A bit it's basically synchronous (though weak memory model) but synchronous with respect to servicing a TLB miss
<geist> i think that's pretty much the same on all arches, x86 included
<heat_> oh yeah AF most probably won't fire until the instruction retires
<heat_> just like a normal exception works
<geist> but D bit (or equivalent) is different because it can be written back at any time afte the TLb entry was brought into existence
<heat_> cuz, you know, that would be confusing as hell
<geist> totally
<geist> but since AT is an instructin that retires, it can also fire an AF
<heat_> yep
<geist> cache instructions have a similar property, iirc
<geist> riscv i think behaves more or less identically except id esont' have a separate access fault exception, so it's confusing as shit
<geist> it just fires a general page fault, and it's softwares problem to figure out why
<heat_> yeeehaw riscvriscvriscv
<geist> yah that's one of the handful of major design flaws that i'd love to see fixed
<Bitweasil> Hm. I think I found better info, once I dug into it.
<Bitweasil> "An address translation in struction is permitted, but not required, to set the Access Flag in the translation table entries for that address."
<heat_> geist, wait, riscv does vector out the page fault exceptions, so wdym?
<Bitweasil> Silly me, I was looking for it in the AT instruction descriptions. :/
viatatribal has joined #osdev
<geist> Bitweasil: yeah question there is if it does in reality
<geist> heat_: well, i mean it doesn't separately call out access fault exceptions, or otherwise have any bits that tell you why it threw that PF
<Bitweasil> Sure, but I don't have a test harness on actual hardware up to play with. :/
<geist> it has 3 PF exceptions: instruction, data read, data write, but + the address is all you get
<geist> no flags that tell you any more info than that
<heat_> yeah but isn't that all you need?
<heat_> x86 doesn't tell you anymore than that IIRC
<geist> yah but x86 doesn't have access faults
<heat_> any more
<heat_> oh right i remember this problem
Arthuria has joined #osdev
<heat_> and your code didn't look at the PTE so solving it was ugly?
<geist> it's not insurmountable, but it means on access faults you have to do a bunch of extra work
<geist> which is annoying, because one of the poitns f access faults is they happen a lot and they should be cheap as a result
<geist> well, it means you have no choice but to look at the PTE, then decide what the problem was, and resolve it
<Bitweasil> I mean, hopefully it's in the cache, if it's just been walked?
<geist> at least on ARM it says 'there was an access fault, right here <pointer to it>' so you can build a fast path that justdives in once to your page tables, sets the bits, and moves on'
<heat_> i don't think access faults can be cheap tho
<heat_> always painful to handle
<geist> well, no, but you can at least assist the software to help
<heat_> set the PTE, then set any LRU logic you need, then set PG_accessed or whatever
<Bitweasil> ^^ Yeah. ARM has it as a separate and easily detected fault type.
<geist> in our code we have to come in through the generic PF path, query the page table, then decide 'ah everything seems in order but the A bit isn't set, probably this is an A bit exception'
heat_ has quit [Remote host closed the connection]
heat has joined #osdev
Arthuria has quit [Ping timeout: 255 seconds]
<sortie> And now truncate(2) also properly shrinks and frees blocks :D
<geist> and you zero blocks when you extend?
<sortie> Yup
<sortie> Well actually I don't actually zero the bytes until the file size extends that far
<heat> sortie: that's cool but you know what you *can't* do? write a btrfs implementation
<sortie> Like if you truncate to 513 bytes, I will zero the first byte of the second sector and leave the 511 remaining bytes uninitialized
<sortie> heat, nice try
<heat> that'z not a good idea
<heat> zero it all
<heat> once you get mmap those things may leak
<sortie> k I'll add a todo
<geist> yeah but i mean if you suddenly add a MB of new data, you should zero out all of those sectors before wiring it up
<geist> that i've always found to be kinda annoying, sinc eyou have to queue a huge amount of io and block on it, basically
<sortie> Yeah technically I do a lazy writing
<sortie> So I am lazy and just do the truncate which zeros a bunch of blocks and marks them as dirty
<geist> yah i remember beos had this bug, and it was a total security problem, since you could uncover all sort of shit on the disk
<sortie> And then I do pwrite afterwards which does the same
<geist> but this was in the 90s when no one cared
<sortie> But the background thread writing them out has probably not even run and just writes the end result
<ChavGPT> search for lbolt
<sortie> My
<sortie> My FAT driver is pretty odd because I just forked my ext2 driver and kept it compiling at all times, so it's full of dead ext2 code that is slowly being replaced
<sortie> Lots of aborts around to make sure that code doesn't run
<sortie> The main stuff is being replaced but there's lots of ext2 utility functions still around, like getting indirect blocks
<geist> yeah i made the mistake of also trying to write my fat driver in C++, so got a bit off into the weeds with that
<geist> though it's come off okay
<geist> like it's still basically procedural, but there are convenient C++ utility classes you can do that help a lot. like store a cursor for the last write that the inner lookup routines can use
<geist> and try to share a lot of that logic
<sortie> yayyyyy it's time to implement O_CREAT
<sortie> That should be easy enough
<geist> yah and of course the dir shit is where it gets annoying as heck. that was kinda my first big task: deal with the VFAT stuff
<geist> haha, wait until you deal with LFN
<sortie> Haha I'm gonna MS-DOS this shit
<geist> word. that makes it a lot easier
<sortie> Just ignore LFNs and open the ~1s and what not
<geist> though really the LFN stuff doesn't make create any worse, you jsut have to precompute how many consequetive entries you need and then search for an empty run of those
<sortie> LFN is all built so it'll recover if you ignore them
<geist> yep, it's terribly clever actually
<geist> in that it's terrible, and clever at the same time
<sortie> And it's not even that clever
<sortie> But it gets the job done
<sortie> In the most terrible way
<geist> well, the semi graceful dealing with older implementations trashing it is pretty decent
<sortie> geist, the more complicated problem is actually allocating a unique short name
Left_Turn has joined #osdev
<geist> yeah, though i seem to remember the algorithm wasn't too bad
<sortie> Is there an algorithm?
gog has joined #osdev
<sortie> I recall seeing there is a preference for what to allocate
<sortie> But doing it perfectly seems very expensive
<gog> hi
<geist> well, the algorithm is basically truncate it, add the ~1, then *exhaustively search the dir for a collision*, retry if you do
<geist> but then that's the other fun of CREAT: case insensitivity, which means you have to search the dir first for a match
<sortie> Right now I'm just considering it as an upper case only filesystem
yoyofreeman has quit [Remote host closed the connection]
Turn_Left has quit [Ping timeout: 240 seconds]
<geist> oh heh yeah i guess i hadn't dealt with it yet: https://github.com/littlekernel/lk/blob/wip/fat/lib/fs/fat/dir.cpp#L480
<bslsk05> ​github.com: lk/lib/fs/fat/dir.cpp at wip/fat · littlekernel/lk · GitHub
<geist> but this is why it's WIP
<netbsduser``> they describe the microsoft algorithm for lfn shortname generation in the efi fat32 spec
<geist> but yeah it's basically take first 6 letters, replace the rest of the 8 with ~1 and then try that, increment and repeat
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<geist> and once you get to 10 i think you need to move to 5 letters, repeat
<geist> i forget how the extension is handled
<sortie> Extension is unmodified
<geist> yeah but if you have a file like .jpeg i dunno what you do
<netbsduser``> you only do the first 3
<geist> truncate the extenion? yeah okay
<geist> or .tar.gz
grumbler has joined #osdev
<sortie> If you encounter a .jpeg, convert it to a NFT and ransom it back to the author
<geist> win!
<ChavGPT> my kernel is on the blockchain
xenos1984 has quit [Read error: Connection reset by peer]
<mcrod> hi
<gog> hi mcrod
<mcrod> gog may I pet you
<gog> yes
* mcrod pets gog
* gog prr
<Cindy> hey gog girl
<gog> hi
<Cindy> can i get like pets
* gog pet Cindy
* Cindy purrs
<Cindy> thank you sis
xenos1984 has joined #osdev
<mcrod> does qt ever get less annoying
<mcrod> seems not
<sham1> No
<sham1> It's a clear example of legacy code
<sham1> And even as an ardent fan of legacy code, it's always a tradeoff
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 260 seconds]
<heat> ardent fan of legacy code
<bslsk05> ​github.com: illumos-gate/usr/src/cmd/ls/ls.c at 6bc074b1c1f7d3014541f4c3e3152dcf2b19eed6 · illumos/illumos-gate · GitHub
<geist> from xenix i'm sure
<kazinsal> oh yeah xenix code
<geist> i think they were still futzing with it about then?
<heat> yep, xenis all the way
<heat> xenix
<heat> xenis is something else hehe
<kazinsal> I think they sold it off wholly to SCO in 89
<geist> looks like the last release was 1989
<heat> i think the SVR4 x86 stuff was full of microsoft code
<kazinsal> microsoft used it internally for a whole after that
<heat> so probably just xenix stuff
<kazinsal> iirc their mail servers were all xenix until exchange matured enough to handle their scale
<geist> at some point i futzed with it on an emulator, tried to boot it on my 386
<geist> i think it needed more ram than i had
<kazinsal> it's a bit finicky
<geist> yeah
<heat> what's up with these illumos commit messages?
<geist> like very early 386bsd or whatnot, you need pretty much a specific set of hardware
<kazinsal> I should give it another shot booting in 86box now that their pre-pentium emulation is pretty close to cycle accurate
<heat> is this some boomer format from CVS or something?
<geist> hmm, where?
<bslsk05> ​github.com: History for usr/src/cmd/ls/ls.c - illumos/illumos-gate · GitHub
<heat> 13397 ls calls time() many more times than necessary
<heat> whereas a traditional git-ish commit msg would be something like "ls: call time() less times" or whatever
<kazinsal> I'd assume it's a reference to a bug tracker
<geist> and was probably extracted out of CVS i suspect
<geist> if the history goes back that far they were most definitely not using git at the time
<kazinsal> yeah, it's their bug tracker IDs
<bslsk05> ​www.illumos.org: Bug #15027: The ls command should show SIDs instead of ephemeral IDs - illumos gate - illumos
<heat> wow they take the bug tracker stuff really seriously
<heat> bizarre
<bslsk05> ​github.com: sort · openbsd/src@fec4f05 · GitHub
<heat> s o r t
<heat> wait wtf illumos uses gerrit?
<heat> woah
<heat> i really wasn't expecting that
Turn_Left has quit [Read error: Connection reset by peer]
<ChavGPT> heat: illumos commit messages are rather special
<ChavGPT> key difference from the rest of the world is that they they don't even consider them important past bug number
<ChavGPT> and it is the bug number with all the info
<heat> yeah
<heat> i mean, at least they make sense
<heat> it's just odd
<ChavGPT> 1234 performance should not suck
<heat> UNIX using a bugtracker and gerrit??
<ChavGPT> still open
<ChavGPT> i don't know what they are on today
<ChavGPT> i know they changed bugtrackers few yeras back
<ChavGPT> but i don't recall from what or to what
<heat> they use redmine for bug tracking atm
<heat> (apparently)
<ChavGPT> wow excellent oepnbsd commit message
<ChavGPT> how did you run into that shite
<ChavGPT> would be funny if the list was stillu nsorted
<bslsk05> ​github.com: --csv is an extension; ok millert · openbsd/src@7a6df6a · GitHub
<heat> first commit i've seen that starts with --
<ChavGPT> called it
<ChavGPT> makefile is still unsorted big time :d
<bslsk05> ​github.com: Fix a bad cast to char * that causes incorrect results on big endian. · openbsd/src@0a9776f · GitHub
<heat> the gang doesn't understand aliasing or strict aliasing or pointers or types
grumbler has quit [Quit: It's time]
<heat> >Revert the previous. It was committed by my mistake.
<heat> holy shittttttt
<heat> >revert previous, it doesn't help
<netbsduser``> no one understands strict aliasing
<heat> >reporter had radeondrm disabled when testing
<heat> holy cow i can't take this i need to stop
<sortie> heat, boom, O_CREAT.
<heat> sir you have a typo
<heat> it's O_CREATE
<sortie> heat, it is actually O_CREATE in Sortix.
<heat> gosh there was this really funny patch in glibc where the guy just renamed O_CREAT to O_CREATE
<netbsduser``> next thing you know they will try to rename SIGCLD to SIGCHILD
<sortie> fork -> fuck
<geist> hmm, subtle armv8 thing someone just pushed to LK
<bslsk05> ​github.com: [arch][arm64] Fix mmu_unmap issue when FEAT_TTL is implemented by shavitmichael · Pull Request #386 · littlekernel/lk · GitHub
<geist> notably, the top bits of the register you fill out for TLBI instruction you really need to make sure you dont have any extra bits set in there where they dont need to be
<geist> a case of RES0 -> new use (FEAT_TTL)
<heat> oh ew thats so sneaky
<geist> yeah i'd been splattering bits all over the top of that register since day one, and it hasn't mattered until now
<geist> and QEMU even ignores them, even if it declares FEAT_TTL to be present
<kazinsal> huh
<geist> he had discovered it by deubging LK running on an ARM fastmodel, which is a very precise emulation
<heat> wait
<heat> where's the problem?
<geist> so it was following the rules, and if you dig into the FEAT_TTL feature it's cray cray
<geist> the problem is with FEAT_TTL there's a new field off the top of the VA addrss in the target register
<geist> and 00 means 'old behavior' but anything else has some new meaning
<heat> doing like reg = vaddr >> 12; seems like it wouldn't splat over any reserved bits?
<heat> oh wait, i see
<geist> if you're splatting a 0xffff.... address yes
<heat> vaddr is smaller than 64 - 12
<geist> the instruction has always said to put vaddr[55:12] there, but i was just shifting >> 12 and not masking out the top bits
<geist> also possible it's always been trashing the ASIDs....
<kazinsal> iiiiinteresting
<geist> since the asid takes up the top 16 bits of the register
<kazinsal> hazards of reusing bits previously described as "zero" in an optional feature I guess
<geist> anyway, double check yuor code in case you made the same mistake
<heat> yeah i just >> 12 too
<heat> i have many problems in my borked arm64 port :/
<bslsk05> ​developer.arm.com: Documentation – Arm Developer
<heat> it's a tough arch
<geist> describes the layout of the register
<bslsk05> ​developer.arm.com: Documentation – Arm Developer
<geist> so yeah i think i had even more of a bug there, sicne it would or a bunch of 1s into the bottom of the ASID field
<heat> wow
<heat> arm64 really is hard
<geist> oh heh we only fixed it in zircon a little while ago.
<heat> steve ballmer: x86 x86 x86 x86 x86 x86 x86 x86 x86
<geist> ah i see it wouldn't have been a problem in the zircon branch, because we only use global addresses in the kernel, and thus use the 'all ASID' versions of the TLBI there
<netbsduser``> heat: its top problem is its outrageously long and sparse manuals of which there are many
<netbsduser``> they define the format of nonterminal PTEs in a different manual to terminal PTEs, for goodness sake
<heat> yeah
<geist> what, arm?
<geist> no they dont
<geist> it's just really really verbose
<netbsduser``> i certainly couldn't find the definitions in the same manual
<netbsduser``> i remember having to check a different one
<geist> the problem is you can legitimately miss finding things like that, because the manual is so big and hard to find stuff
<geist> but my guess is you weren't looking at the proper ARM ARM
<netbsduser``> quite
<geist> which technically has pretty much everything, but is gigantic
<netbsduser``> that may be the case, i have a big folder full of PDFs and i pick whichever one sounds right
<geist> whic may be the issue
<geist> precision is required here
<netbsduser``> i made a start on an aarch64 port of my kernel but getting through the manuals to find relevant information is just so tedious
<geist> tis why i find riscv so fun. it's like exactly the opposite
<netbsduser``> while for the 68k port i just refer to the 500-page 68040 or 68060 manual
<geist> for good or ad
<netbsduser``> i might make a start on a riscv port
<geist> it's pretty fun, honestly
<geist> it's refreshingly simple, though the manual is frustraing in different ways
<geist> it's also a case of you need to find the right manuals and read them i the right order, since it's spread across many docs
<sortie> heat, and boom, FAT mkdir(2).
<geist> dont forget . and ..!
<sortie> Already done
<geist> i was honestly surprised to see those entries in there, since there serve mostly no purpose in fat
<sortie> I even have the special case where .. exists but the cluster is 0 if the parent is the door
<sortie> *root
<geist> but i guess it, like we mentioned before, there to be a minimal amount of core state needed to get around
<geist> ie, an open file handle on a dir is sufficient to traverse the fs
<geist> useful on machines where 10s of bytes to store the mounted state is what they were trying to achieve
<sortie> I want to stress the fact that I have FAT truncate(2), pwrite(2), O_CREAT, and now mkdir(2).
<geist> have we been insufficiently impressed?
<sortie> That's the 88 miles per hour speed, geist
* geist presents sortie with tribute
* geist slaughters a goat and drops it on sorties living room coffee table
<sortie> Marty, you got the camcoder?
<netbsduser``> now you just need to make it fast
<netbsduser``> i haven't looked at how microsoft fastfat does this yet
<heat> lmao
<sortie> Fast? Where we're going we don't need fast!
* geist sees the Winnebago come around the corner
<geist> actually wait, VW van
Matt|home has quit [Quit: Leaving]
<geist> the fun joke about that whole scene is there's no way a deloran can go 88mph
<sortie> Step 1. mformat -F /dev/ahci0p3 ← Nuke my EFI system partition
<sortie> Step 2. fatfs /dev/ahci0p3 /boot/efi ← Mount the new empty FAT filesystem as the EFI system partition
<sortie> Step 3. grub-install --target=x86_64-efi --removable /dev/ahci0
<sortie> Step 4. Enjoy the existence of /boot/efi/EFI/BOOT/BOOTX64.EFI
<heat> ok now do unicode case folding
<heat> btw why removable?
<sortie> Step 5. Reboot
<bslsk05> ​github.com: lk/lib/fs/fat/dir.cpp at wip/fat · littlekernel/lk · GitHub
<geist> unicode is for chumps
<bslsk05> ​github.com: Libc/gen/wordexp.c at master · Apple-FOSS-Mirror/Libc · GitHub
<ChavGPT> what the fuck
<heat> HAHA
<ChavGPT> not mine
<ChavGPT> was given to me
<ChavGPT> that said
<geist> haha, wekk ut at least has a /* XXX - this is not meant to be fast */ comment
<sortie> heat: --removable makes it install EFI/BOOT/BOOTX64.EFI. Otherwise it
<sortie> Otherwise it uses the bootloader distro id as the subdirectory name, and installs as grubx64.efi -- LOWERCASE
<sortie> --> I need LFN.
<heat> oh haha that's cute
<heat> lowercase needs LFN?
<geist> yep
<heat> i thought it just gets collated into SCREAMING
<sortie> It does
<sortie> But I am case sensitive
<geist> i think the moment you use lower in anything, it generates a LFN
<sortie> I can't have opening a lowercase file succeed and turn uppercase
<geist> though 'it' may be different based on if you're linux/windows/etc
<geist> may be that windows will SCREAM it for you
<heat> sortie, sure you can
<sortie> heat: The lack of --removable also means I need to register the bootloader in the EFI variables, or go into the firmware and do it manually
<heat> linux even explicitly supports that
<heat> on ext4!
<sortie> heat, but if I use EFI/BOOT/BOOTX64.EFI then I can rely on the EFI fallback without kernel EFI support
<geist> oh gosh i forgot that LFNs fill backwards for some dumb reason
<heat> yeh
<geist> i'm re-reading through my LFN extraction logic and it's a nightmare
<sortie> char namelen; char name[]; ← what's so hard, FAT :(
<heat> but you didn't
<heat> you implemented FAT
<sortie> I did lots of stuff
<heat> now you add proper EFI support
<sortie> I already did that
<geist> well, i see why. you see the last sequence first, which is special: holds a magic sequence number and the checksum
<heat> the gang struggles with EFI runtime services not crashing the whole machine
<sortie> Except the kernel EFI variable driver stuff
<geist> then subsequent LFN entries must be sequence + 1 and match checksum
<sortie> heat, but like I said, that's optional
<geist> that was part of the kinda clever and terrible part
<sortie> heat, I implemented the EFI system partition support in libmount and disked, so you can make it. I added some support to sysinstall also
<sortie> (although the sysinstall stuff is unfinished, needs to be finished now that the rest works)
<heat> can you even detect EFI atm?
<heat> probably not right? mb1 has no efi support
<sortie> Technically, no. multiboot 1 isn't telling me that. But I can easily detect it in GRUB's config and just forward a --firmware=efi option to the kernel as a quick hack
<sortie> I already have the kernelinfo(2) "firmware" syscall that lets userspace know if it's bios or efi, I planned ahead
<sortie> heat, anyway yeah I need to finish this up with polish and document it, but now I got all the minimum pieces to officially support EFI. Next we'll make it a good implementation :)
<heat> congrats!
<sortie> _D
<sortie> :D
<sortie> Thanks heat :)
<sortie> This was a fun challenge
<heat> "fun"
<heat> FAT lmao
<heat> i'm not doing FAT any time soon
<heat> i would rather implement zfs than FAT
<sortie> Hmm, it was fun
<sortie> I'm skilled enough to just do FAT and do it well
<sortie> And honestly I enjoyed hacking on FAT done natively
<sortie> geist, I actually developed this FAT driver entirely natively on my Sortix laptop :D
<sortie> The best kind of filesystem hackin'
<sortie> Hoping you don't accidentally brick your dev env
<geist> noice
<sortie> Heyyy I can explore my test FAT filesystems in the firmware's selection menu, it got a graphical fs explorer when selecting the bootloader
heat has quit [Quit: Client closed]
heat has joined #osdev
goliath has quit [Quit: SIGSEGV]
nyah has quit [Quit: leaving]
bauen1 has joined #osdev