pabs3 has quit [Remote host closed the connection]
_ngn has joined #osdev
vdamewood has joined #osdev
Arthuria has quit [Ping timeout: 276 seconds]
<_ngn>
ok i dont understand paging, how does cpu resolve a virtual address using the tables? i looked it up and it seems like cpu takes different parts of a given address and uses them as an offset for the each table, if thats the case how do you even identity map using a simple linear paging setup?
<the_oz>
get the setup working for 1 page of memory, pretend you are the MMU "resolving" for that single page
<_ngn>
ok so i didnt understand any of that
<_ngn>
im just tryna setup paging to switch into long mode
<_ngn>
if i understand it correctly cpu does all the address resolving stuff after you enable paging, no?
<the_oz>
no, you have to set up the data for the CPU to work first before enabling paging
<_ngn>
i know
<_ngn>
after creating a linear paging setup and placing the address of pml4t to cr3
<_ngn>
you enable paging
<the_oz>
you also have to make sure segmentation works, whether you use segmentation or "not"
<_ngn>
so i need to make sure segmentation works before setting up paging?
<the_oz>
yes
<zid`>
ngn: it's just a tree
<_ngn>
paging?
<zid`>
array of 512 ish entries (depends on cpu), pointing to other arrays of 512
<zid`>
eventually you end up with a physical address at the end
<_ngn>
i understand that
<_ngn>
how does cpu resolve that
<zid`>
That's it.
<_ngn>
thats what im tryna understand
<zid`>
each array entry covers 1/512th of the range left
<zid`>
until 1/512 == 4096, or whatever the page size is
<zid`>
on amd64 the first layer is 256TB, each entry controls a 512GB range
<zid`>
The next layer controls a 1GB range
<zid`>
The next layer controls a 2MB range
<the_oz>
as the MMU you pull together pieces of the address which parts specify where in these tables you end up at whether a valid address or not, bailing out early as the pieces are assembled
<zid`>
The last layer controls 4kB ranges
<zid`>
(which are just the physical addresses)
<_ngn>
the_oz, so the mmu resolves a virtual address, not the cpu?
<zid`>
so if you wanted to translate the virtual address of 0x100001000000 (1TB + 16MB)
<zid`>
the mmu is inside the cpu, in almost all cpus you'll meet irl
pabs3 has joined #osdev
<_ngn>
oh ok i thought its a component of the kernel or smthng
<the_oz>
MMU is among ALU and um
<zid`>
MMU is the hardware that does the lookups in these tables (and segmentation and other things)
<_ngn>
so like mmu takes the first x bits and uses it as an index for the first table, then takes the next x bits and uses it as an index for the second table etc.?
<zid`>
That's the [1]th entry on the top level, which contains a pointer to a 2nd level table, we want the [0]th entry in that, which points to a third level table, and we want the [8]th entry in that, which contains a pointer to a table containing 512 physical addresses, of which we want the [0]th
<zid`>
yes
<_ngn>
then how does identity mapping even work
<zid`>
you just put the same physical address in as the virtual address that would take you to that table entry
<zid`>
The very first piece of code on 'setting up the paging' infact, uses entry 511 in the pml4, and pdpt, which would be the final 512GB range, and the final 1GB range inside that range
<zid`>
i.e -1GB
<zid`>
which is 0xFFFFFFFFC0000000 if I counted right
<the_oz>
too many bytes for my fingers
Gooberpatrol66 has joined #osdev
<_ngn>
which piece of code?
<zid`>
(amd64's address range is split into negative and positive, -128TB to +128TB)
Gooberpatrol_66 has quit [Ping timeout: 260 seconds]
<_ngn>
the pseudo c code?
<zid`>
pagedir_t* PDT = PML4[511]->PDPT[511];
<_ngn>
ok thats not what im talking about tho
<_ngn>
see the rest of the code, it adds a single entry for each of the tables
<zid`>
I was responding to what you said, you said each table has a single entry, I said no, and the page even uses them such that they have 512
<_ngn>
except for the last one
<zid`>
No, every layer has an entry filled out
<_ngn>
the rest of the entries are left as zeros
<_ngn>
how is it filled out
<the_oz>
because getting started with a single page of memory with the rest marked not present is how you get started, I mean you could immediately fill it out too but
<zid`>
It does pml4[0] = pdpt; pdpt[0] = pd; pd[0] = pt; for(i = 0; i < 512; i++) pt[i] = 0x1000 * i;
<_ngn>
yes thats exactly what i said
<zid`>
I'd claim the last layer very has an entry set
<_ngn>
theres just a single pml4, a single pdpt, a single pd, a single pt which is completely filled
<zid`>
right
<zid`>
which should map 512*4096 bytes of memory from 0x0 to 0x0
<zid`>
by using a 4k mapping from 0 to 0, a 4k mapping frm 0x1000 to 0x1000, a 4k mapping from 0x2000 to 0x2000, ...
<zid`>
To map any more, it'd need to use pd[1] = pt2; pt2[0] = ...
<zid`>
where pd[0] covers the first 2MB in its range (0x0 to 0x1FFFFF), pd[1] covers the 2nd 2MB in its range (0x200000 to 0x3FFFFF)
<_ngn>
ok i see the thing with this setup u should not be able to access any address thats larger than 0x1f
<_ngn>
thats what confuses me
<zid`>
You cannot, not
<zid`>
or it could leave a huge gap and use pd[500] = pt2; and then whatever it wrote into pt2 would be mapped to 1000MB instead
<the_oz>
the access results in a chance to provide memory AND paging data for the access
<the_oz>
a paging fault
<zid`>
so you could have half your 4MB jpeg appear at 0x0 and the other half appear at 0x1000, without actually having to copy the data anywhere
<zid`>
at 0x1000000*
<zid`>
or have the first half appear twice
<zid`>
whatever silly thing your OS decides it wants to do
<_ngn>
the last 6 bits is used as an offset for the last table, rest is used for offsetting other tables
<the_oz>
by setting the data IN the paging tables
<_ngn>
with this setup we only have a single entry in the other tables
<zid`>
because <=2MB is mapped, yea
<_ngn>
any address larger then 0x1f should not be accessible
<zid`>
are not
<_ngn>
so thats true?
<zid`>
yes
<_ngn>
but thats like 31 address
<_ngn>
31 addresses*
<zid`>
it's 2MB of addresses.
<_ngn>
wdym
<_ngn>
0x0 to 0x1f
<zid`>
> by using a 4k mapping from 0 to 0, a 4k mapping frm 0x1000 to 0x1000, a 4k mapping from 0x2000 to 0x2000, ...
<_ngn>
i dont understand
<zid`>
I never mentioned byte granularity in my explanation, you invented that yourself, I always mentioned page sizes
<zid`>
This is not mapping bytes
<zid`>
it is mapping 4096 byte regions
<_ngn>
i still dont understand
<zid`>
Each page.
<zid`>
Is 4096 bytes long.
<_ngn>
yeah?
<zid`>
If I map one page to a specific physical address.
<zid`>
I have picked the position for *4096* bytes
<_ngn>
you map 4096 addreses
<zid`>
not 1 byte
<zid`>
so if I do 1 mapping, I map 4096 bytes, if I do 2 mappings, I map 8192 bytes
<_ngn>
i understand that but then how does the cpu or the mmu whatever is it resolve it
<zid`>
It does pml4[0] = pdpt; pdpt[0] = pd; pd[0] = pt; for(i = 0; i < 512; i++) pt[i] = 0x1000 * i;
<zid`>
maps 4096 bytes, 512 times
<zid`>
addition?
<zid`>
[0x7000-0x7FFF] is mapped to [0x7000-0x7FFF]
<zid`>
what is 0x7232 mapped to?
<_ngn>
i think im stupid
<_ngn>
i still dont understand
<zid`>
do you understand what "[0x7000-0x7FFF] is mapped to [0x7000-0x7FFF]" means?
<_ngn>
can u just walk me through the process of resolving the address 0x1983?
<zid`>
I mean, that's the very very first thing I did, but we can do it again
<zid`>
0x0000000000001983
<zid`>
is in the first 512GB region, which you can figure out with some shifts and masks
<zid`>
so it's pml4[0]
<zid`>
it's in the first 1GB region of that 512GB region, which you can figure out with some shifts and masks
<zid`>
so it's in pdpt[0]
<zid`>
It's in the first 2MB region of that 1GB region of that 512GB region, which you can figure out with some shifts and masks
<zid`>
It's in the *second* 0x1000 region of that 2MB region of that 1GB region of that 512GB region, which you can figure out with some shifts and masks (0x1983>>12 gives 1)
<zid`>
so pt[1] contains the physical address mapping 0x1000 somewhere
<zid`>
and if you were doing an actual memory access, we'd access the 0x983th byte of that region
<zid`>
_ngn: I'm a hotelier and my hotel has 5000 rooms. I am clever and put 1000 rooms one each floor of my hotel. You walk up to me and ask me which floor room 1983 is on. I tell you floor 1.
<zid`>
s/one each/on each/
<bslsk05>
<zid`*> _ngn: I'm a hotelier and my hotel has 5000 rooms. I am clever and put 1000 rooms on each floor of my hotel. You walk up to me and ask me which floor room 1983 is on. I tell you floor 1.
<zid`>
oh... thanks botboy
<_ngn>
i think ive a different understanding of how the cpu resolves an address
<_ngn>
please check the image
<zid`>
well, the thing I said is literally what I said
<zid`>
and the image agrees
<zid`>
other than being a completely different paging system
<zid`>
(3 level paging with 128 byte pages)
<zid`>
And my hotel is 1 level paging with 1000 byte pages.
<zid`>
and amd64 is 4 level paging with 4096 byte pages
<_ngn>
ok im stupid my bad
<the_oz>
MMU takes a virtual address, cuts it apart, which pieces are indexes into paging tables it was prepared with. The indexes are the virtual address, the contents are a physical address
<zid`>
It's just a lookup from one set of integers to another set, with a granularity of the page size.
<_ngn>
i thought that image was 4 level paging
<the_oz>
the act of resolving virtual to physical is effectively a key, value lookup, with more steps but essentially
<_ngn>
so i thought last 5 bits were being used for indexing the last table
<zid`>
yea no the last bit isn't a table, as you just noticed, it's a memory range
<the_oz>
yeah it all is contained by a singular memory page
<zid`>
oh I meant 64 byte pages for the last image
<the_oz>
thus offset
<zid`>
so that's just the 36th byte of that range
<the_oz>
I ain't even trying to do math
<zid`>
base 64 is really not easy to talk about, I prefer my hotel.
<the_oz>
it's a good analogy simile thingy
<zid`>
or at least base 4096, because then you can write each layer in hex using 0x000 to 0xFFF :P
<zid`>
_ngn: So, now that you're untangled, notice how all the physical addresses the code writes end in 0x000?
<_ngn>
thank you guys a lot i should've double checked the image
<zid`>
pt[i] = 0x1000 * i;
<_ngn>
which code the long mode setup article?
<_ngn>
oh that one yeah?
<zid`>
That's actually beacuse.. those low bits are useless, you can't map 0x1000 to say, 0xDEADBEEF0000050
<zid`>
with an offset like that, it has to be page aligned
<zid`>
those low bits are actually where the flags live
<_ngn>
yeah i do understand that
<zid`>
a lot of people fuck that up and try to do addr<<12 | flags
<zid`>
instead of addr | flags
<zid`>
so I am just pre-empting it
<zid`>
The flags overlap the address in the entry.
<zid`>
because the address is *guarenteed* to have 12 useless bits
<_ngn>
yeah it has to be aligned with the minimum size of 4096
<_ngn>
thats why right?
<zid`>
yea, which is xxxx000
<zid`>
in hex
<_ngn>
thats clever because you use less space for an entry
<_ngn>
but its also annoying and confusing
<zid`>
Hence me pre-empting it
<_ngn>
like same with the gdt
<zid`>
gdt entries are a *mess*
<_ngn>
however is caming up with these formats i hope they go to hell
<zid`>
the address bits aren't even contiguous in those are they
antranigv has quit [Ping timeout: 252 seconds]
antranigv has joined #osdev
m3a has quit [Ping timeout: 255 seconds]
agent31475 has joined #osdev
<_ngn>
also is there a good way to debug the "enabling paging" process?
<_ngn>
using gdb when something goes wrong i get "Cannot access memory at address [next instruction]"
<zid`>
qemu has 'info tlb' and stuff
<zid`>
but cannot access memory at next instruction means you failed to identity map the page you were running from
<_ngn>
"info tlb"?
<zid`>
yes, in qemu
<_ngn>
is there like qemu console that i can enable?
<zid`>
yes
<zid`>
try -monitor stdio
<_ngn>
oh okay let me check it out
<_ngn>
thank you
<zid`>
it also is on the dropdowns in the gui builds I think?
<_ngn>
i was using dwords while setting up the tables
<_ngn>
mb
<zid`>
yea, you need two dword writes, but not to do them back to front :p
<zid`>
if you want a tip for remembering, little endian is the good endian, where things type pun correctly. so if you write 0x17 to memory as an int, then read it back as a byte, you get 0x17 back
* the_oz
swaps the order of the writes in the file
<the_oz>
JOB DONE
levitating has quit [Remote host closed the connection]
GeDaMo has joined #osdev
<_ngn>
alright thank you zid and the_oz
<_ngn>
have a great rest of your day yall
_ngn has quit [Quit: WeeChat 4.4.1]
strategictravele has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
chiselfuse has quit [Ping timeout: 260 seconds]
netbsduser has joined #osdev
chiselfuse has joined #osdev
heat has joined #osdev
Left_Turn has joined #osdev
theyneversleep has joined #osdev
theyneversleep has quit [Remote host closed the connection]
npc has joined #osdev
npc has quit [Remote host closed the connection]
op has joined #osdev
vdamewood has quit [Quit: Life beckons]
childlikempress is now known as Mondenkind
cow has quit [Ping timeout: 252 seconds]
cow_ has joined #osdev
marcopolo2 has quit [Quit: Connection closed for inactivity]
<zid`>
Praise me, I did some osdev type things in #osdev
<GeDaMo>
I thought "thank you zid" sounded out of place :P
<zid`>
I am very helpful if the other person is not a horrendous vampire with the IQ of a sausage roll
<zid`>
We just don't get many
<Mondenkind>
zid`: waow
<nikolar>
good job zid`, have a cookie
<zid`>
Is it Ratko Mladić flavour
<zid`>
In other news, I installed a silly plugin thing that lets me type accents easily
<zid`>
no, that would be sensible, so that's not an option on windows
<nikolar>
lol
<zid`>
if you hold altgr you get accent accent only, on only aeiou, and € on $
<zid`>
acute accent*
<zid`>
there's an intl layout with dead keys but it's not what anybody uses and it's kinda shitty anyway
<nikolar>
←↓→
<zid`>
default gb linux layout just has something under every key
<zid`>
arrows under wasd, yen under y, etc
<zid`>
not sure how you're supposed to type grave accents etc though
<nikolar>
lol
<nikolar>
for me it's altgr+7 then a key
craigo has quit [Quit: Leaving]
<nikolar>
though it's not gb
<zid`>
altgr-7 is impossible to press
<nikolar>
how
<nikolar>
ù
<zid`>
fingers don't work that way
<zid`>
have to rotate wrist
<zid`>
to reach across
<nikolar>
lol complain to whoever made this
<nikolar>
because that's how it is on my keyboard
<zid`>
your keyboard implements it?
<nikolar>
*keyboard layout
<nikolar>
my bad
<zid`>
well it's more of an IME thing
<nikolar>
i haven't messed with any ime stuff
<nikolar>
this is pretty much default x11
<nikolar>
or xorg rather
<zid`>
I should install SERBIAN and see if it's as insane as portugal was
<zid`>
onyx is basically encrypted
<nikolar>
Lol
<nikolar>
sr-latin is what you need probably
<zid`>
( on F4, ) on ctrl-alt-break
<nikolar>
Unless you want Cyrillic
<zid`>
[ on meta-super-z, ] on shift-.
cow_ is now known as cow
edr has joined #osdev
joe9 has joined #osdev
mrkajetanp has joined #osdev
qubasa_ is now known as qubasa
frkazoid333 has quit [Ping timeout: 276 seconds]
qubasa has quit [Remote host closed the connection]
op has quit [Remote host closed the connection]
spareproject has joined #osdev
spareproject has quit [Remote host closed the connection]
op has joined #osdev
vai has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
vai has joined #osdev
ramenu_ has joined #osdev
stolen has joined #osdev
freakazoid332 has joined #osdev
steelswords has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
steelswords has joined #osdev
voidah has joined #osdev
goliath has joined #osdev
voidah has quit [Remote host closed the connection]
voidah has joined #osdev
voidah has quit [Client Quit]
levitating has joined #osdev
voidah has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
xenos1984 has joined #osdev
voidah has quit [Remote host closed the connection]
voidah has joined #osdev
agent31475 has joined #osdev
<kof673>
if m68k is back, then... https://0x0.st/s/7xkgesBub-wYCevplGASrw/XvKb.lha actual lyrics: Oh no no no no I, I don't want to follow the PC side, oh no no no no I, I can't stop dreaming with Amiga in the sky. Forever and ever, and ever and ever I'll live like Marty Mc Fly...
[Kalisto] has quit [Read error: Connection reset by peer]
stolen has quit [Quit: Connection closed for inactivity]
terrorjack4 has joined #osdev
aethlas has quit [Quit: bye]
<sortie>
Today in osdev: I may have found a gcc 14.2.0 compiler bug, or at least I get a warning in very specific circumstances that doesn't make sense to me
<cow>
haha wow
<sortie>
https://paste.ahti.space/beba41.html ← I get a -Wdangling-pointer warning in editor's input.c under very specific brittle circumstances. It's reproducible on Linux too I don't even understand what the warning is trying to say. Here's the minimal reproduction, I was unable to remove anything more and still get the warning.
<bslsk05>
paste.ahti.space <no title>
aethlas has joined #osdev
<sortie>
I mean it's possible it's a problem in my code (this is the minimal reproduction; I removed as much as I could) but it should be fine
theruran has quit [Quit: Connection closed for inactivity]
levitating has quit [Ping timeout: 248 seconds]
X-Scale has joined #osdev
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
Gooberpatrol66 has quit [Quit: Konversation terminated!]
Gooberpatrol66 has joined #osdev
tru3humandesign has joined #osdev
levitating has joined #osdev
tru3humandesign has quit [Ping timeout: 248 seconds]
aethlas has quit [Read error: Connection reset by peer]
levitating has quit [Read error: Connection reset by peer]
levitating_ has joined #osdev
<dostoyevsky2>
where actually is the kernel in https://github.com/redox-os/redox ? I see installer, redoxfs, relibc but I see no real kernel subdir... odd... also why is relibc necessary? libc implemented in rust?
<dostoyevsky2>
I expect the kernel to be full of unsafe...
<dostoyevsky2>
heat: ah, thanks!
<heat>
kernel does not need to be full of unsafe unless you do unsafe things
<heat>
... like interfacing with C code
<Matt|home>
hello. i have a new computer coming in today. after months of not having a working one. yay.
<heat>
fwiw re rust it seems to me that it's much easier to write low-level rust if you don't have to adapt existing C interfaces
Gooberpatrol_66 has joined #osdev
<heat>
so basically something from scratch
<heat>
whether this is strictly true, i dunno
Gooberpatrol66 has quit [Ping timeout: 260 seconds]
<dostoyevsky2>
heat: I heard if you want something like linked lists in Rust, that can be very challenging... And redox's kernel having roughly 35K LoC and 610 mentions of unsafe seems similar to rust_os with 95K LoC and 1.6k of unsafe
<heat>
yeah but even if linked lists are fucked to write in rust, you write them once and it's done and dusted with
<heat>
same shit for unsafe
<heat>
it's not exactly a big problem unless you enjoy rolling your own improved linked lists every time you write your C code
<heat>
s/improved/improvised/
<bslsk05>
<heat*> it's not exactly a big problem unless you enjoy rolling your own improvised linked lists every time you write your C code
<heat>
(meaning struct S { /* ... */ struct S *next, *prev;} plus custom append/remove code)
<heat>
as for the unsafe the numbers the rust for linux project touts are pretty impressive... whether it's representative i dunno
Matt|home has quit [Ping timeout: 256 seconds]
<nortti>
they've wrapped the filesystem APIs such that you can implement FSs in rust, anything else big yet?
<dostoyevsky2>
nortti: In Linux?
<heat>
android binder has been written in rust
<nortti>
dostoyevsky2: yeah
<heat>
i don't think there's an actual filesystem written in rust yet
<nortti>
ah
<heat>
remotely near upstream that is
<heat>
but the bcachefs guy really likes it soo
<dostoyevsky2>
nortti: One of the guys who's responsible for Rust in Linux stepped down like one days ago
<heat>
tbqh i think the rust for linux project has been really slow and really too experimental for its own good
gog has joined #osdev
<heat>
and most kernel devs really don't want to write shit in rust either
<dostoyevsky2>
nortti: It seems to me that Linus didn't think that throught and now Rust and C devs are each others throats
<heat>
most people interested in kernel rust would not be doing kernel development unless for "ahhhhhhhh rost langauge"
levitating_ is now known as levitating
<heat>
introducing a new language is contentious yeah
<dostoyevsky2>
So they are having "discussions" like here: https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529 where a C kernel dev tells a Rust dev that they aren't going to rewrite all the filesystems in Rust
<heat>
they failed to introduce C++ (C with some funky new features)
<heat>
rust is even worse
<puck>
okay i got distracted and creduced sortie's failure into
<puck>
`int a, b; void e(char *); void d(void) { char c; if (&c != (void *)1) return; if (b) a = c; e(""); } void f(void) { d(); }`
<nortti>
didn't they try c++ really early on?
<nortti>
like, pre-standard c++
<heat>
and immediately discarded it yeah (or so I've heard)
<heat>
there was an actual patch set on april fools that converted the kernel into a g++ compileable thing
<nortti>
heh
<heat>
and there was some dust lifted wrt that. a bunch of actual kernel devs were somewhat in favour of C++ support
<heat>
that was followed by a swift "no." or just lack of response in general
<the_oz>
you know what's better than an RMS past? A pinkhair commie future
<heat>
and this is a language that can literally take almost all C headers and compile them into C++
<gog>
woke pronoun-havers
<gog>
i do have the urge to dye my hair pink again tho
<heat>
i have no pronouns
<heat>
refer to me as "the heat"
<gog>
yes the heat
<nortti>
how does the heat express deixis?
<netbsduser>
i don't know why the rust people are so surprised
* heat
googles what deixis means
<heat>
the heat still does not get what deixis is
<nortti>
"this", "that"
<gog>
despite the memes i still haven't learned rust
<nortti>
"then"
<netbsduser>
gnu/linux is notorious not merely for not providing stable kernel abis but for total opposition thereto
<heat>
netbsduser, the whole controversy is severely overblown
<heat>
i saw the vid, it was nothing special
<heat>
a little heated, but the argument was valid
<netbsduser>
heat: i just watched it and i was quite surprised
<nortti>
I don't think there's anything in the rust-in-linux work requiring stable ABI?
<heat>
well it kinda requires a stable API
<netbsduser>
the resignation notice of that Rust4Linux mogul made it sound like he was shouted down as the antichrist, like ian paisley's denunciation of the pope in the europarliament in 1988
<heat>
they're dragging this all over reddit like "hurr durr linux toxic"
<nortti>
only to the extent that rest of the kernel does
<netbsduser>
but instead it's just a moderately heated guy loudly but not uncivilly stating that rust is secondary to improving the c apis around filesystems
<heat>
nortti, basically the whole argument was: "rust guy": "we're encoding a bunch of behavioral info in the type system" "ted tso": "this is not stopping us from screwing around and improving VFS and we're not respnsible for the rust bindings"
<nortti>
these two positions seem to not be in any kind of conflict?
<heat>
which is natural because none of these people are rust experts or even know rust
<netbsduser>
i will say i felt a bit uncertain about what to think when i saw the cryptic threat against linux in the resignation letter but this incident is much less severe than i expected
<the_oz>
heat: dunno I just am learning what deixis, but upon first glance this seems to be why "ma, my, me" are close to one's self as a nurterter of the self and "pa, that, there" are contrapositive in relation to the self
<heat>
nortti, i think they just dont want pushback tbqh
<heat>
and it hasn't really been accepted in the kernel world because the kernel world generally does not like big revolutions but incremental improvements
<kof673>
just made me think "i am not this" "i am not that" "there is no such a thing as a person" vaguely "buddhist" lol
<the_oz>
apparently it's a lexical phenomenon in a lot of languages? whatever
<kof673>
"the heat" cannot be fathomed
<heat>
like no one is going to RIIR the whole vfs layer
<nortti>
right, the thing that is confusing to me here is that the RiL project seems to have been incremental
<heat>
and in the meanwhile the rust effort still depends on experimental features, on rustc, no llvm alternative, no spec, no gccrs
<the_oz>
>no one would ever redo and mess shit up badly
<the_oz>
*german smirk*
<nortti>
but yah, the fact that the experimental features are needed makes me think the current status of "you can write stuff in it, but it's not used in any core subsystem" makes sense
<heat>
nortti, i just ran "find . -name *.rs" in my local bleeding edge linux mm-unstable tree
<heat>
two files were part of actual functionality (two drivers basically)
<nortti>
which ones?
<heat>
./drivers/net/phy/ax88796b_rust.rs
<heat>
./drivers/block/rnull.rs
<nortti>
heh
<heat>
the rest is basically just rust infra
<heat>
out of 66 .rs files, only two are actual users
<heat>
anything else has not hit upstream whatsoever
<nikolar>
and those two were experimental to asses the api i think
<nikolar>
a rewrite of simple c drivers
<geist>
rnull, a heavy hitter
<nortti>
< heat> and in the meanwhile the rust effort still depends on experimental features, on rustc, no llvm alternative, no spec, no gccrs ← actually, is the rustc gcc backend (not to be confused with gccrs) not usable for rust-in-linux?
<ramenu_>
err, sorry to intrude on the conversation here. but if someone could answer this, it would be greatly appreciated (not answering is fine too). If the TSS iomap_base is larger than the TSS limit size, the process should not lookup the IO bitmap and just deny user processes port access, right?
<heat>
nortti, >This requires a patched libgccjit in order to work
<heat>
i assume this is still heavily experimental
<nortti>
ah, I heard it was upstreamed into the compiler, but I guess only the rustc side of it got upstreamed
<nortti>
yeah from what I understand llvm and maybe cranelift is where the focus goes primarily
<geist>
ramenu_: hmmm. gotta page this back in
<heat>
is this a swapping reference??
<geist>
that's a good question actually
<geist>
i *assume* that the TSS limit size has to include it
<geist>
lemme see
<heat>
yeah i can't help there, i haven't messed with the io bitmap
<geist>
looking in the zircon code, we use it
<ramenu_>
that's what the intel manual says at least, i think.. but it doesn't seem to be working for me :/
<ramenu_>
"If I/O map base is greater than or equal to TSS limit, the TSS segment has
<ramenu_>
no I/O permission map, and all I/O instructions in the 80386 program cause
<ramenu_>
exceptions when CPL > IOPL."
<geist>
the answer seems to be yes, it does need to include the bitmap
<geist>
just double checked the code
<geist>
that's also how you can 'truncate' the bitmap if you only care about some of the lower io ports
<ramenu_>
geist: thank you.
qubasa has joined #osdev
<heat>
btw geist here's a fun fact: linux does not support splitting huge page mappings (MAP_HUGETLB, not transparent huge pages)
<heat>
which totally sidesteps the "what to do if you need to split a large page" problem
<heat>
this is kind of totally random but i vaguely remember you speaking about this problem aaaaaaaaaaages ago
<heat>
years probably
qubasa__ has joined #osdev
qubasa has quit [Remote host closed the connection]
<mcrod>
hi
<nikolar>
oi
pdziepak has quit [Ping timeout: 264 seconds]
op has quit [Remote host closed the connection]
tru3humandesign has joined #osdev
netbsduser has quit [Ping timeout: 255 seconds]
dgz has joined #osdev
<geist>
heat: interesting, so they avoid at least that whole part of break-before-make
<geist>
so it just treats a large page mapping as a single unit. also i guess that means they can't really transparently large page map if it just so happens to work out huh
<heat>
oh they can, that does indeed split huge pages
<heat>
but explicit "map this as a huge page mapping" mappings do not support it
dgz has quit [Ping timeout: 272 seconds]
<heat>
which is actually fair, because those mappings do indeed promise everything is going to be a huge page, so if you break up a huge page mapping it turns out it's not true anymore
xenos1984 has quit [Read error: Connection reset by peer]
<geist>
oh gotcha
<heat>
bbm is actually literally the worst and i'm glad i can ignore it for a while
xenos1984 has joined #osdev
<geist>
yeah, avoid it in the kernel too, since even if you do it right you must create the possibility of a stray page fault in the kernel on an SMP system
<geist>
in user space, well stray page faults are just a thing in SMP
<heat>
it does sound like it's just saner to not support any permission changes for kernel mappings at all
<heat>
or at least heavily restrict it into "if you do this you get to keep both pieces if it crashes and burns"
<geist>
yah and for arches that have A bit faults, make sure you just set it always
Left_Turn has quit [Read error: Connection reset by peer]