\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
<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
<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
<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]
<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
<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>
THE IMPORTANT HEADLINE HERE IS THAT **I IMPLEMENTED EFI IN SORTIX**
<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