<geist>
right. both 2 and 4 byte instructions can start on 2 byte alignments. provided the cpu implements compressed instructions
<geist>
though... it does beg the question if the cpu *doesnt* then can it run a 4 byte instruction on 2 byte boundary. i doubt it
<geist>
since having the compresed feature implies the hardware to deal with 2 byte alignments
<mrvn>
now write me a code that has 2 functions that overlap with an offset of 2 bytes.
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<geist>
hmm?
Likorn has quit [Quit: WeeChat 3.4.1]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
kingoffrance has quit [Remote host closed the connection]
Likorn has joined #osdev
<mrvn>
if you jump to x you get one function and if you jump to x+2 you get another function.
<geist>
ah yeah finding an instruction that if you branch into the middle of it you get another valid instruction would be interesting
<geist>
but i did just check and yes only with the presence of the compressed instruction feature do branching to 2 byte offsets become valid. otherwise regular branches do let you encode a +2, but you'll get an unaligned instruction fault
<geist>
and of course you can also indirect through a register and get a
<geist>
+1 unaligned as well
<geist>
biut basically the uncompressed (4 byte) ISA is designed around the presence of the 2 byte ISA, because it lets you encode PC relative offsets in units of 2
<geist>
or obviously higher because of the future expansion space of 48 or 64 or whatnot byte instructions
<clever>
on some ISA's, you also get a naked 32bit immediate operand appended to a 16bit opcode
<clever>
so you can put any 32bit value you want into that 32bit half of the "48bit opcode"
<clever>
and now technicallities come in, do you count the immediates as part of the opcode?
<clever>
for some encodings, they share bytes, and for others they dont
Matt|home has joined #osdev
orthoplex64 has quit [Remote host closed the connection]
orthoplex64 has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
smeso has quit [Quit: smeso]
srjek has quit [Ping timeout: 248 seconds]
smeso has joined #osdev
nyah has quit [Quit: leaving]
pretty_dumm_guy has quit [Ping timeout: 256 seconds]
<geist>
clever: generally no. you'd consider that to be part of the instruction, but not the opcode per se
<geist>
but what is precisely the opcode vs the instruction varies a lot based on the ISA, how it's laid out, and how the bits are distributed
dmh has quit [Quit: rip]
Matt|home has quit [Ping timeout: 276 seconds]
<clever>
with something like 6502, i think every opcode is exactly 8 bits, but the operands are variable, so its trivial to decode with just a switch statement
xenos1984 has quit [Read error: Connection reset by peer]
Matt|home has joined #osdev
<clever>
but ive seen others with a far more variable width, and operand + opcode mixed into the same bytes
<clever>
though i'm not familiar with exactly how much of arm/x86 fall into each camp
xenos1984 has joined #osdev
<geist>
in general a lot of older arches you can decode with some sort of semi tree
<geist>
ie, decode the first byte, then a lot of those you're done, or you know how many additional bytes to fetch
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_dog has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
* geist
yawns
Burgundy has joined #osdev
w41 has quit [Ping timeout: 240 seconds]
<zid>
tasuketteeee loidomaaaaan~~~
<geist>
mrvn: not that i endorse what you're doing with mega.nz, but i did enjoy the show
<zid>
It's called netflix password sharing, it's all the rage
<zid>
I disapprove because he's using websites instead of private trackers
<geist>
and generally blabbing about it online
<geist>
mega.nz iirc is the one that simply shares encrypted blobs, and the URL itself you visit has the aes hash in it to decode what you're looking at
<geist>
so they theoretically legitimately dont know what they're hosting
<zid>
yea
<zid>
I wonder what the TTL is
<geist>
never looked into it, but i dont know precisely how they can avoid 'seeing' the URL
<geist>
since foo/bar/baz/HASHHERE would still show up as a fetch on their servers, right?
<zid>
don't log it, and then process the ?.. in javascript I guess
<geist>
even if it was foo/bar/baz?HASHHERE?
<geist>
or does stuff after ? not get sent to server?
<zid>
it does
<zid>
PHP exposes it as $_GET[] for example
<zid>
a hashmap
<geist>
so maybe there's an extension to privately have args that stay local?
<zid>
Just don't log the reqs
<zid>
and the server only has it in ram for a few ms
<geist>
oh sure but my point is you dont know if they're *not* doing it
<zid>
doesn't matter though really, they're doing it for their own legal argument benefit
srjek has joined #osdev
<geist>
right but then of course they could easily be legally compelled to log everything from your IP or ip range and then silently do it
<geist>
and they can't legitimately say 'nope we have no idea what they're doing'
<GeDaMo>
The filename is not evidence of what the file contains :P
<geist>
no but it's a 'trivial' transformation to take the URL and decode it, since the URL itself contains the key to decrypt it
<geist>
my point is the key itself ends up in the http fetch, so you can't completely claim its 100% client side
<geist>
also reminds me i should look more into protonmail. seems like a decent service
<geist>
but i haven't really done the due diligence to see if they're as secure as they claim
<mjg>
heh
<mjg>
this makes me wonder how popular piracy is today in my home country
<mjg>
before 2013 or so it was the only option to watch wstern stuff
<mjg>
that is unless you don't mind waiting 5 years and have the thing butchered with bad translation and a lector voice over it
<mjg>
that's not the word
<geist>
yah that's super dumb. artificial segmentation of the markets based on locale specific licensing agreements is dumb
<mjg>
how do you call it properly in english
<geist>
heh i've never heard 'lector voice' before but it pretty instantly makes sense
<jimbzy>
dubbing?
<mjg>
no, dubbing having a dedicated voice actor per character
<mjg>
is*
<GeDaMo>
Narrator?
<mjg>
in poland you got a person reading lines for literally everything
<geist>
oh lector voice is worse than that? oh wow
<jimbzy>
Wow
<geist>
yah okay that's super bad
<geist>
do they at least usually give you subbing? i almost always prefer to watch stuff subbed anyway
<mjg>
you can easily get cancer if you undersatnd spoken english on top of it and hear partial words :)
<jimbzy>
Hah
<mjg>
today i have no idea, back when i was watching tv (so 20 or so years ago), no
<geist>
sometimes countries will have all these rules that X percentage of stuff must be in native languag,e etc
<mjg>
it was *really* bad man
<geist>
and he ate people
<jimbzy>
That sounds like America, geist. We tell people they have to learn our language because we're too dense to learn theirs :p
<mjg>
GeDaMo: does not sound right
<geist>
'murica!
<mjg>
i was about to say it's a shitty audiobook, but even those tend to have multiple voice actors
<mjg>
shitty audiobook with visuals :-P
<jimbzy>
Readin' don't never not done nothing for not nonebody. Never not no one, didn't about no reason not never. And by God they never not ain't gonna will!
<mjg>
i'm confident most people in .pl aged 30-40 who speak good enough english to use in practice
<mjg>
only do it because of pirating us shows
<geist>
jimbzy: for some reason i thought you were in canada, but then i think everyone is either n canada or uk
<geist>
which isn't true
<jimbzy>
Nah, I'm in Missouri, USA.
<mjg>
i would role play being in candaa, but apparently that would mean i would have to be polite
<geist>
missouri fuck yeah!
<mjg>
so f-word no
<mjg>
fuck missouri
<geist>
mjg: yah you should role play being in boston or something
<mjg>
apoloogies, maybe you are from here
<geist>
then you can talk about pahking your cah
<jimbzy>
Hah
<jimbzy>
Wolk the dowg
<geist>
seattle, there's not much to make fun of
<geist>
or portlanders
<mjg>
i can give you some lines from italians in new jersey
<jimbzy>
Missouri is a strange state outside of the cities.
<bslsk05>
'Accent Expert Gives a Tour of U.S. Accents - (Part One) | WIRED' by WIRED (00:21:32)
<jimbzy>
It depends, geist. Living in a rural-ish part of California gave me a bit of a Mexican accent. It's not quite Spanish, but it's close.
<heat>
yeah
<heat>
poland is pretty big lol
<geist>
kinda a let down because as he goes farther west over the course of it he basically says 'meh there's not a lot of interesting stuff here except southern california'
<mjg>
heat: i would not say big
<geist>
since most of the west coast is effectively midwestern 'plain' american english
<geist>
with little tweaks
<jimbzy>
It really is.
<geist>
but yeah that's where you get the biggest influences in california at least, mexican influences
<bslsk05>
en.wikipedia.org: List of countries and dependencies by area - Wikipedia
<geist>
mjg: population wise i think only a handful of states are close to poland though. 37mil according to google
<geist>
so probably the usual big ones. new york, texas, california
<jimbzy>
geist, I was actually called "racist" for my accent once and I was like "Nah, this is just the way I talk?"
<mjg>
oh heh, australia bigger than the entire european union
<mjg>
did not realize that
<geist>
oh actually only california has more (39mil)
<jimbzy>
I also have an inner french accent that comes out from time to time that I got from my father's side of the family.
<geist>
the next one down is in the 20s (texas)
<mjg>
geist: smaller population count helps more languages though due to bigger amount of disjoint communities
<mjg>
geist: as in not in everyday contact
<geist>
yah. i remember someone from norway telling me years ago there are tons of norweigan dialects that are really not mutually intelligable. i was surprised, but i guess if you think about it there are probably lots of isolated villages and whatnot
<geist>
due to cold ass weather
<geist>
and of course having been there a long time
<geist>
not unique to norway of course
<mrvn>
geist: I liked it too. I would pay them to watch it but they always insist of dubbing it before letting me see it.
<geist>
mrvn: yah i've been watching all the new star trek shows, but so far they've been pretty bad. Picard especially so
<mjg>
geist: i can tell you there is a village 50km from my hometown which already speaks a highly detached dialect
<geist>
so i'm a little more than neutrally enthusiastic about BNW
<heat>
mjg, poland is not small in area and in population, especially wrt europe
<mjg>
geist: you can make heads and tails of what they mean, but good luck saying anything
<mrvn>
geist: mega sees what url you access but they don't know the encryption key so can't know what is in the blob.
<jimbzy>
mjg: My family arrived in North America in the 1610's and we didn't learn English until the 1950's :p
<mrvn>
The key is a js variable in the URL that isn't send to the server
<geist>
mrvn: but isn't it in the key? i thought there was a long hash as the entire tail of the url you visit?
<geist>
ah but i dunno right? wouldn't that be in the initial fetch?
<mjg>
jimbzy: not particularly shocked. my grandfather spent over 20 years in chicaco and did not learn squat
<mjg>
jimbzy: thanks to living in a de facto polish area
<mjg>
jimbzy: i know the scale is different, but i suspect it happened in a similar manner :-P
<jimbzy>
Yeah that's how my ancestors were. It was a small, geographically isolated French community.
<heat>
also a lot more french immigrants
<mjg>
oh french? that cranks it up to 11
<mjg>
no offence. maybe you have french roots.
<heat>
was missouri part of the north american french colonies? I think so
<bslsk05>
en.wikipedia.org: Missouri French - Wikipedia
<mrvn>
mega can't know what in the blob but if someone complains they take it down. Or if it doesn't get accessed too long and isn't linked from a paid account anymore.
<geist>
okay now about that osdev
<mjg>
this palce was so nice for the last half hour
xenos1984 has joined #osdev
<mjg>
you had to ruin it, did not you
<heat>
computer
<mjg>
i was looking for a new sitcom to watch
<mjg>
without laughtrack
<mjg>
turns out the landscape is pretty bleak
<heat>
you should read the ACPI spec
<heat>
there's no laugh track there
<mrvn>
How to implement the Miller-Rabin primality test for 64bit numbers using witnesses 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, and 37.
<graphitemaster>
It's not called osdev unless it comes from an isolated French community, otherwise it's just sparkling software development
<mjg>
heat: once i almost got myself into writing a uefi loader for linux from scratch
<mjg>
heat: not my fault though
<heat>
do it
<heat>
bet you won't, pussy
<mjg>
hold my acpi spec
<mrvn>
Specifically: What's a good way to square a 64bit number modulo N with 64bit arithmetic?
<mrvn>
and 64bit number * one of the witnesses modulo N
<heat>
i enjoy kernel
<heat>
not number
<heat>
number bad
<heat>
memory allocation good
<mrvn>
tried to allocate a prime sieve for 64bit numbers but I run out of address space
<heat>
good thing riscv has support for 128 bit
<mjg>
mrvn: just copy paste something from stackoverflow like a webdev would do
<heat>
w3schools*
<mjg>
also i agree with heat
<mrvn>
So just use __int128?
<heat>
i also agree with heat
<heat>
mrvn, no, get a rv128 cpu
<mrvn>
Me, myself and I object.
<heat>
object oriented mrvn
<mrvn>
If I had a 128 bit cpus I would add 41 as witness and extend it to n < 3,317,044,064,679,887,385,961,981
vimal has quit [Remote host closed the connection]
<GeDaMo>
I'm Hicks, he's Hudson :P
<geist>
hmm, so i moved the vid card from one slot to another and now the server has been running for nearly 2 days. still not multiple times the usual MTBF, but interesting anyway
<geist>
could just be reseating the card was sufficient
<mrvn>
did you try putting it back in the first slot?
<geist>
not yet. probably will wait another day so it's at least 2x the usual MTBF
<mrvn>
Just removing and plugging it back in might have rubbed off some oxidation.
<geist>
yah exactly. really i should have done that first: just reseated everything
<geist>
if it magically started working then there was something like that and move on
<mrvn>
got any contact spray?
<zid>
I also failed the "should have just reseated it" test last week
<zid>
my monitor 'died' at random during use
<zid>
turns out the port was a little.. spring loaded, and had ejected the hdmi cable like a gun
<geist>
huh interesting
<jimbzy>
I used to get issues like that with ISA cards.
<zid>
The usual retaining mechanism of 'bit of bent steel' to try keep the plug friction-fit
<zid>
combined with the cable only being 85% of the way in
<zid>
-> port is trying to spring the cable out of the port
<zid>
you'd know exactly what I meant if you felt it
<jimbzy>
My neighbors crack me up. If one person on the block decides to mow their lawn everybody fires up their mowers and does the same.
<jimbzy>
Pavlov's landscaper.
<geist>
yah also interesting that this is an x1 video card now plugged into an x16 slot. which doesn't hold it at all
<geist>
especially since it can't get to the clip at the end of the slot
<zid>
I hope you have a lego-man to hold the end up
<geist>
it's actually the reason i have this card: x1 vid cards are rare, but it's great because you can plug it into a derpy x1 slot so i can use the wider slots for more important cards
<geist>
liek an x4 10gbe
<zid>
aren't all video cards 1x
<heat>
no they're x16
<zid>
up to
<geist>
right. most video cards you find are x16 width physically
<zid>
they will work fine on, as low as 4 imperically
<zid>
but I assumed 1x would also work
<geist>
right, but then they physically wont plug into an x4
<zid>
1x slots all have open backs on my board
<geist>
that's the problem. it's a physically x1 card, so it physically plugs into everything
<geist>
ah well nice for you. mine do not
<zid>
nothing a dremel can't fix
<geist>
well if there's other shit in the way actually yes
<geist>
probably a function of your server/workstation style mobo
<zid>
actually does 1x even need the open back, isn't there a notch
<zid>
where the 'end' would be anyway
<zid>
*needs to find a pci-e card real quick*
<geist>
ah i think no. i think it just extends on
<geist>
yah no. the part that's notched off is i think common to everything maybe?
<geist>
or anyway that implies the plastic around the slot would also have to be narrower than the notch
<geist>
which is fairly narrow
<zid>
okay yea they only have one notch, boo
<zid>
so you'd need to dremel out a regular 1x slot
<bslsk05>
wiki.osdev.org: Higher Half Kernel - OSDev Wiki
<mjg>
did anyone do lower half, exluding for lulz perhaps?
<mrvn>
pure convention
<heat>
sortie
<geist>
if you mean just between high and low, on x86 not really. you can do either
<geist>
it's convention
<Maka_Albarn>
ah. thank you.
<geist>
some arches mandate it however, so in general it makes sense to follow the convention
<heat>
Maka_Albarn, in x86_64 someone needs to use the lower 2GB and someone needs to use the higher 2GB, for more efficient code
<zid>
lower half probably makes vm86 really really difficult
<geist>
BeOS, for example, had them inverted
<geist>
probably other kernels that did too, but that's the only one i know of off the top of my head
<mjg>
quite frankly i autocorrected "higher half" to having it mapped to begin with
<mrvn>
zid: why? you plan to use the first 1MB?
<Maka_Albarn>
vm86 is completely under 1MB, my kernel is loaded at 1MB, so the vm86 shouldn't be a problem
<mjg>
you know what would be funny
<mjg>
kernel using 2G in the middle
<zid>
mrvn: you're going to add checks for that to your is_kernel()? gross
<zid>
I'd rather check the sign bit instead of a complicated set of conditions
<geist>
pure x86-32 actually user starting at high address really isn't an issue either, if you use user segments that are non zero based
<heat>
zid, ye cant
<heat>
the new amd address tagging disallows that
<geist>
execept obviously modern machines you pay a penalty for non zero based segments
<mrvn>
heat: (addr << TAG_SIZE) < 0
<heat>
they broke the canonicality of the higher address bits and linux kernel people are pissed
<geist>
but at the time (say 386-pentium or so) non zero segments were no real cost, so you could put the kernel more or less anywhere, even in the middle, if you use say 2GB user and kernel segments with a nonzero offset (i think they'll wrap properly)
<geist>
but that's a function of x86-32. other arches either have fixed notions of user/kernel (mips, vax, etc come to mind) or are generally just flat and use paging to do it, like we do now with x86-64
<Maka_Albarn>
hmm...
<Maka_Albarn>
what about a modular kernel where the modules are loaded as higher-half, but the core system is lower-half?
<heat>
why
<mrvn>
If you don't know (or don't like) where the bootloader will place the kernel then higher half has advantages. No risk of overlap when mapping.
<geist>
yeah why is the main thing
<geist>
also 64bit makes most of these decisions completely obsolete
<mrvn>
(assuming the bootloader always goes to lower half)
<geist>
since functionally speaking modern 64bit machines lay out their virtual addresses pretty mnuch the same way
<geist>
though i guess on x86-64 you can still put kernel at 0 and user space at 0xfff8.0000.0000.0000
<Maka_Albarn>
true... if I have my 32-bit code set up as higher-half from the start, then it will be easier to upgrade to 64-bit
<heat>
yeah but your codegen will be bad
<geist>
er 0xffff.8000.0000.0000
<zid>
when does mcmodel=kernel actually do anything?
<mrvn>
I wonder if a system that has physica memory (only) at the higher half would go with lower half kernels.
<geist>
zid: when zero or 1 or sign extending 32bit constants
<zid>
so never?
<geist>
a lot. actually
<zid>
everything is PIE and ASLR and stuff these days in my world
<heat>
except when it's not
<mrvn>
zid: mcmodel=kernel has addresses from -2G to 0 instead of 0 to 4G
<geist>
but note it assumes that code is within -2GB i think so in that case the sign extension is nice
<zid>
I've not used a constant address for anything in a very long time in a program
<heat>
and when it's not, mcmodel=kernel/small is good
<geist>
okay. well if you are okay with the cost then full pie is fine
<zid>
I didn't even think there was a cost
<zid>
riprel is freeeee
<geist>
not entirely no
<heat>
nothing is free
<mrvn>
geist: what cost? doesn't it just give linker errors when you exceed the mcmodel address range?
<geist>
it's very easy on x86 to encode say a sign extended 32bit fixed address in an instruction
<zid>
if nothing is free, everything is free :P
<zid>
that's what riprel already does though geist
<geist>
right, but you can't use that in all contexts i believe
<geist>
so you end up having to compute address with lea and then use it, i believe
<geist>
but honestly idont want to think about it right now
<zid>
oh right maybe a few encodings go missing, but it's not like movsx has a lot of encodings either
<geist>
there's reasons for it. whether or not it matters is <shrug>
<zid>
I bet riprel has more because it's just part of sib, compared to sign extention
<geist>
i mean we're compiling zircon in basically pic mode because of KASLR
<geist>
and i think <shrug> it technically costs something but so it goes.
<mrvn>
heat: if you have mcmodel=large than every function call will be 64bit.
<geist>
i do know that fixed address non pic, large (or is it huge) mcmodel is terrible and you should avoid
<geist>
yah thatssss bad
<heat>
mrvn, yes
<geist>
and furthermore i dont think it's well tested since stuff doesn't use it
<zid>
how does that work? there's no absolute call on x86
<heat>
movabs $symbol, %reg
<zid>
oh, lovely
<heat>
call (%reg)
<geist>
yah play with godbolt a bit and you'll see
<mrvn>
which is like 3 times the size
netbsduser has quit [Quit: Leaving]
<zid>
I bet in practice it's not like.. terrible
<geist>
also pic is equally bad because the riprel cant encode offsets as large as large mode expects
<geist>
so i think it has to do something like get the pc and do the 64bit add manually
<zid>
thunks yo
<geist>
since i think large mode also means sizeof(code) > 2GB as well
<zid>
combining it with pic sounds amazing
<geist>
but yeah the more i think abouti t, i think mcmodel=kernel mostly applies for non PIC modes
<geist>
because then you can encode kernel addrfesses with a 32bit sign extended thing
<zid>
right it only really 'does' anything with 64bit absolute addresses that you can then safely truncate down
<zid>
if everything is relative 32bit addresses already it does nothing
<geist>
something like that
<zid>
I don't think you can convince it that pointers are 32bit at all which would be fun
<heat>
yeah I think mcmodel options make little to no difference when compiling with PIC or PIE
<geist>
but in general there is more overhead to 32bit relative in some cases, so there' still an advantage to non pic mode if you can do it
<geist>
but i can't tell you what it is offhand
<zid>
tack some __attribute__((small)) onto some struct and it movsx's the pointers in it from 32bit
<geist>
this is a case where 30 minutes with godbolt will tell you a lot
<zid>
that'd be neat
<zid>
that's why I was confused geist
<geist>
but frankly i spend most of my brain cells on arm64 and riscv nowadays if i can avoid it
<zid>
because I see people constantly suggest it and in my personal experience, which is roughly 3 or 4 times half an hour, it does nothing
<mrvn>
This discussion makes me want a x86_32 kernel model.
<geist>
x86 is just like slogging into a C++ war. it's a rich battlefield, but meh you just feel dirty
<heat>
we need x86-64 2 the sequel
<geist>
also the fact that modern x86 impls make half of the discussino moot anyway in surprising ways is also an additional layer of slog to muddle through
<geist>
ie, yeah maybe the codegen is worse but then the cpu is tuned for it so it eats it up, etc
<zid>
and.. microop caches means codegen is not what codegen says it is
<zid>
so all you're really eating is L1 miss effects etc
<geist>
interesting, true, but just harder to think about unless it's really important
<zid>
I bet that movabs rax; call rax case is actually like.. really incredibly hard to measure a performance loss for
<geist>
clearly there are folks that are totally interested in it thoug, so not saying you shouldn't be. i'm just whining. <goes back to hacking>
<zid>
unless the predictor just can't handle it
<heat>
are you a hacker geist
* geist
HAX
<zid>
He's a VAX actually
<zid>
Personally, I am anti-vax
<geist>
yah slowly working on this FAT driver
<zid>
I don't think our children should be exposed to it
<geist>
restructuring it so it's ready for the next phase: write support
<heat>
yoo i just had the best idea
<heat>
sancov support
<heat>
i need that
<zid>
murder all the children fi- oh
<heat>
zid, shhhh
<heat>
don't tell everyone my plan B
<zid>
Actually Plan B is to murder them before they're children
<zid>
You're thinking of Preperation H
<clever>
i'm in the mood to write an ethernet driver today!
<geist>
so basically 512 pointers to a descriptor?
<bslsk05>
github.com: linux/bcmgenet.c at rpi-5.10.y · raspberrypi/linux · GitHub
<geist>
i dont want to read it
<clever>
its basically an array of `struct desc { uint32_t length_status; uint32_t addr_lo; uint32_t addr_hi; }; desc[256]` in MMIO space
<geist>
how does rx work as it spans the dsecriptors? there's probably an EOF mark on one of them so it can span multiple RX descriptors?
<clever>
the start/end of packet flags are listed as common
<clever>
and linux drops any packet that is not both the start and end
<geist>
makes sense, fairly straightforward
<heat>
why does that sound like the rtl8168
<clever>
so a packet can span multiple buffers, but linux doesnt allow it
<geist>
it's a pretty standard solution, though i'm surprised the descriptors in mmio space. *usually* those are also in memory, and you jsut set some register to point to them
<heat>
ye
<clever>
some versions of genet are 32bit only, so the addr_hi field is missing
<geist>
that's a lot of latches to hold all of that
<clever>
its probably just blockram at that point?
<geist>
yah probably
<clever>
comments mention that writes to that area can take several 100 nanoseconds
<clever>
and if the host is built in 32bit mode, it skips writing to addr_hi, to save a write
<geist>
right, that'd be the usual reason not to do that
<clever>
if your staying within the lower 4gig, then each packet tx requires 2 x 32bit writes
<geist>
also linux rejecting things that aren't in a single packet is cute, but basically they're syaing the buffers queued are at least a MTU worth so dont bother dealing with splits
<clever>
exactly
<clever>
but the hw has a max buffer size of 4095 bytes (12bit length field)
<geist>
sure but you could queue up say all 1k or 2k buffers, and then let the packet split across them
<clever>
so i'm not sure how linux will deal with jumbo frames over that
<heat>
it won't
<geist>
that's why i was saying there's a SOF EOF bit probably, because then you just read forward and use subsequent buffers
<clever>
yep
<geist>
and then construct a split skbuf for it and pass that up the stack. should handle that
<clever>
the hw allows that, but linux doesnt
<heat>
nah, no split skbuf
<geist>
not sure. i'd be highly surprised if linux doesn't allow a split RX buffer
<heat>
you can't pass NIC rx buffers into the network stack
<clever>
more, that the linux implementation of the driver doesnt allow it
<clever>
the author choose to not support it
<heat>
they allocate an skbuff and copy stuff in
<geist>
huh that's really odd. i'd think any sane net stack would lety ou do that on TX and RX
<clever>
assuming i'm reading the code right
<heat>
a packet can get stuck in processing for a lot of time
<heat>
also, rx'd packets go directly to the queue that recvmsg reads from
<geist>
but i guess maybe they decided that you pay the cost here at the transistion from nic to stack rather than elsewhere
<clever>
heat: you could always change the addr in the rx ring, but that complicates management more
<geist>
my general knowledge of these things is based on BSD style mbufs which i assume also did this
<heat>
you could realloc pages but do you really get that much performance from that?
<geist>
but... maybe not?
<clever>
there is also an optional 64 byte status message, that gets prepended to the packet (for both tx and rx)
<heat>
there's an example of skbuff allocation on RX
<geist>
there's only so many ways to do this really. most designs have pretty much circled in on a similar thing
<clever>
this is basically the same as that ancient 100mbit pci nic i looked at years ago
<clever>
they just expanded it from 4 dma buffers to 256 dma buffers
<clever>
and a packet can now span several buffers
<geist>
what i dunno is what state of the art 10gbe or 25gbe or whatnot nics do. there must be some newer paradigm they move towards
<heat>
in fact they don't seem to handle packets that span multiple buffers here either
<heat>
huh
<geist>
something that offloads even more cpu
<clever>
the next thing i need to investigate, is how to enable rx
<clever>
and deal with irq's
<geist>
heat: e1000e might be interesting to look at, if there's a driver that does the full monty its that one
<heat>
voodoo
<geist>
i do remember the e1000 rx descriptors were a little surprising but makes sense in retrospect
<heat>
the e1000 is not fun to look at
<heat>
there are multiple types of descriptors in the e1000
<geist>
you create a ring of power of N descriptors, and they're *all* power of N size
<geist>
ie, 256, 512, 1024, 2048, etc
<clever>
/* Always use RX_BUF_LENGTH (2KB) buffer for all chips */
<geist>
you set up your pointers accordingly. at first i was ugh, but it makes sense: hardware can up front decide how many descriptors to allocate as it is processing the packet
<clever>
thats half of the buffer the hw reg implies its capable of
<geist>
here's why i think e1000 has to deal with large ass packets: TSO
<clever>
ah, neat
<geist>
the hardware supports the hell out of it, so presumably it's frequently handing the stack up to 64k reassembled packets
<heat>
the rtl8168 also has it I think
<clever>
there is a performance counter i saw in genet, with a label of `RO Rx/Tx 4096-9216 bytes packet`
<clever>
i think its also doing power of 2 based buckets for at least the perf counters
<geist>
you effectively run the nic as if it had a MTU of 64k and let it disassemble/reassemble packets
* Maka_Albarn
yawns
<Maka_Albarn>
still not fully awake
* geist
hunts around for the large trout
<heat>
fun fact: qemu's virtio-net doesn't support any offloading
<heat>
the e1000 does though
<geist>
what kind of offloading?
<heat>
TSO, checksum offloading
<clever>
ok, found the irq handler, now to find the irq#.....
<geist>
TSO no, but i do remember there's at least a feature bit for checksum
<heat>
there's no TSO? I think there is, but I might be wrong
<geist>
for virtio-net that is
<heat>
oh yeah it technically supports all of that
<heat>
but the feature bits are never enabled
<clever>
one table lists them as irq 29 and 30
<geist>
of course checksum offloading for a virtual nic is sort of moot
<clever>
oh, that reminds me of a fun bug i found on the pi2's usb nic
<clever>
from how things mis-behaved, it seems the usb nic is validating the checksum, and then just slapping a "checksum valid" flag on it
<clever>
and then relying on usb checksums to carry the data intact
<Maka_Albarn>
I don't really bother with vms. I just use a spare laptop. need to get a GDB stub integrated though....
<clever>
but, because my usb phy was mis-configured, it silently corrupted packets, and linux didnt re-check the tcp/ip checksums
<heat>
Maka_Albarn, that seems insane
<heat>
you definitely should
<Maka_Albarn>
heat: lol
<heat>
99.9% of my deving is in VMs
<heat>
s/in/for/
<Maka_Albarn>
need to upgrade my malloc/free system and set up serial comms first.
<clever>
oh, does qemu already support genet?
<heat>
no?
<geist>
hmm: virtio-net host features (0x39bf8064): CTRL_GUEST_OFFLOADS MAC GSO MRG_RXBUF STATUS CTRL_VQ CTRL_RX CTRL_VLAN GUEST_ANNOUNCE CTRL_MAC_ADDR
<clever>
heat: correct!, no trace of genet in qemu master
<geist>
seems to be what it's advertising to me now. i think i print all the flags
<heat>
hmmmmmmm
<clever>
ok, now lets see if i can get any irq out of this...
<heat>
geist, do you have bits 0, 7, 8 and 10?
<heat>
i check for those for csum, tso4, tso6 and ufo
<bslsk05>
fuchsia.dev: RFC-0078: Kernel Sanitizer Coverage for Fuchsia Fuzzing
<geist>
cool
<heat>
i want to see if I can get some fuzzing
<heat>
inspired by some guy who just fed afl into AF_NETLINK and fuzzed that
<heat>
syzkaller would be ideal though
<geist>
yah it's pretty cool, i think it takes some energy to retarget it for non linux, but i think it's pretty flexible
<heat>
yup
<heat>
my platform is sufficiently similar to linux or one of the BSDs, i imagine i'll need to do something similar to them
Gooberpatrol66 has quit [Remote host closed the connection]
Gooberpatrol66 has joined #osdev
Likorn has joined #osdev
<mjg>
there is bsd support for it
<mjg>
it can't be that hard then
<mjg>
i mean at least in terms of time invistment
<mjg>
investment even
<mjg>
and by bsd i mean free, net and open all have it
<mjg>
so...
<geist>
yah i think the main trouble weith zircon was it was sufficiently foreign at the syscall layer it took some more work
<geist>
based on general assumptions of posixness, how handles work, etc
<geist>
gosh you know one feature i wish i had from rust is redeclaring a variable as const in the middle of a function
<geist>
that's really handy
<mjg>
hm
<mjg>
funny you say that, a feature i wished for just yesterday was "make it writable only by this magic routine without having to fuck with it by wrapping into a struct"
<mjg>
as in i have a shitload of places which read something, but now i need to make it not-writeable as a fut shooting prevention measure
<mjg>
and i can't add const without compilation breaking in aleph0 places
<mjg>
the standard c cumbersome fuckery would be to wrap it into an opaque struct and patch all places to use an accessor
<heat>
love standard c cumbersome fuckery
<heat>
it's part of the C experience
<mjg>
#ifndef FUCKING_HEADER_H
<mjg>
i only actively notice it when i can't fix it up in 1 minute, like with the above
<heat>
i don't fuck headers but i also dont kink shame
<heat>
you do you homie
<jimbzy>
If you're not having stress dreams about memory allocation then you're not getting your money's worth out of C.
<mjg>
thanks, i appreciate your opennens
<heat>
jimbzy, goto out;
<geist>
ahaha
<mjg>
jimbzy: if you are not having stress dreams about the compiler messing a jmp maze out of your fast path, that's when you are not getting the c experience
<geist>
that one goes into some sort of osdev quotes file
<jimbzy>
Yeah, no shit.
<heat>
if you haven't reinvented object oriented programming in C, you're not doing it right
<mjg>
i would argue you are doing c right if you shit on the language
<heat>
C++ is bad but struct file_operations is peak programming
<jimbzy>
Sometimes you just have to reach around the Lexan, run the compiler and hope for the best.
Burgundy has quit [Ping timeout: 256 seconds]
ngc0202 has joined #osdev
troseman has joined #osdev
heat has quit [Remote host closed the connection]
orthoplex64 has quit [Remote host closed the connection]