channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=22&m=5&d=7
00:13:00 <geist> right. both 2 and 4 byte instructions can start on 2 byte alignments. provided the cpu implements compressed instructions
00:14:00 <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
00:14:00 <geist> since having the compresed feature implies the hardware to deal with 2 byte alignments
00:18:00 <mrvn> now write me a code that has 2 functions that overlap with an offset of 2 bytes.
00:32:00 <geist> hmm?
00:54:00 <mrvn> if you jump to x you get one function and if you jump to x+2 you get another function.
00:58:00 <geist> ah yeah finding an instruction that if you branch into the middle of it you get another valid instruction would be interesting
00:59:00 <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
01:00:00 <geist> and of course you can also indirect through a register and get a
01:00:00 <geist> +1 unaligned as well
01:00:00 <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
01:01:00 <geist> or obviously higher because of the future expansion space of 48 or 64 or whatnot byte instructions
01:11:00 <clever> on some ISA's, you also get a naked 32bit immediate operand appended to a 16bit opcode
01:11:00 <clever> so you can put any 32bit value you want into that 32bit half of the "48bit opcode"
01:12:00 <clever> and now technicallities come in, do you count the immediates as part of the opcode?
01:12:00 <clever> for some encodings, they share bytes, and for others they dont
03:01:00 <geist> clever: generally no. you'd consider that to be part of the instruction, but not the opcode per se
03:01:00 <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
04:10:00 <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
04:10:00 <clever> but ive seen others with a far more variable width, and operand + opcode mixed into the same bytes
04:11:00 <clever> though i'm not familiar with exactly how much of arm/x86 fall into each camp
04:34:00 <geist> in general a lot of older arches you can decode with some sort of semi tree
04:34:00 <geist> ie, decode the first byte, then a lot of those you're done, or you know how many additional bytes to fetch
12:53:00 <mrvn> clever: ARM (like most RISC) has 32bit fixed opcodes (ignoring thumb). x86 is the worst I believe with prefix byte after prefix byte.
12:54:00 <clever> yeah, arm-32 and arm-64 both have a 32bit instruction, with ??? split between opcode and immediates
12:54:00 <clever> thumb is 16bit only
12:54:00 <mrvn> m68k has 16bit "opcode" with very short immediates I think. And the operand encoding can specify extra data words after the opcode.
12:54:00 <mrvn> clever: lets say 16bit instructions.
12:55:00 <mrvn> and 32bit instructions
12:55:00 <clever> kind of like having a virtual pc+2 register#, that you can insert into the reg field?
12:55:00 <clever> so the reg field could be r0, r1, r2, pc+2
12:55:00 <mrvn> clever: no, like "mov mem, reg" on x86.
12:56:00 <clever> id usually call that an ld
12:56:00 <clever> that also gives me a whack idea
12:56:00 <mrvn> add imm, reg
12:56:00 <clever> modify the x86 objdump, so it calls all loads/stores by ld/st
12:56:00 <clever> when it disassembles
12:56:00 <clever> how much can we RISC x86? lol
12:56:00 <mrvn> you could think of it as a pc+2 register but register numbers have a fixed number of bits in the m68k instruction and they are all taken.
12:57:00 <mrvn> You could probably reduce the x86 instructions down to a subset that is risc and ignore the rest.
12:58:00 <mrvn> the conditional codes would be a problem, very un-risc.
13:09:00 <mrvn> I wonder how much of the instruction set something like tinycc uses. A large amount you can only utilize with good optimization.
13:10:00 <clever> there is also an x86 compiler that only uses mov, and nothing else, lol
13:10:00 <mrvn> mov or mov+cmov?
13:10:00 <clever> https://github.com/xoreaxeaxeax/movfuscator
13:10:00 <bslsk05> xoreaxeaxeax/movfuscator - The single instruction C compiler (is fork /371 forks/7458 stargazers/NOASSERTION)
13:10:00 <clever> never looked that closely
13:11:00 <clever> https://github.com/xoreaxeaxeax/movfuscator/blob/master/overview/mov_asm.png
13:11:00 <bslsk05> github.com: movfuscator/mov_asm.png at master · xoreaxeaxeax/movfuscator · GitHub
13:11:00 <clever> looks like just mov?
13:12:00 <mrvn> how do you branch with that?
13:12:00 <clever> i assume mov has conditional execution
13:13:00 <clever> > The inspiration for the compiler is the paper "mov is Turing-complete", by Stephen Dolan http://stedolan.net/research/mov.pdf
13:15:00 <mrvn> I think it manipulates CS to jump
13:16:00 <mrvn> Connecting to stedolan.net (stedolan.net)|185.120.20.29|:80... failed: No route to host.
13:16:00 <mrvn> :(
13:20:00 <mrvn> Hmm, that paper is cheating. It uses "only mov (and a single jmp to loop the program)"
13:21:00 <mrvn> So no, mov is not turing complete. mov + jmp start are.
13:22:00 <clever> i saw a vid earlier, where a guy wrote asm using only ascii printable bytes
13:22:00 <clever> and basically, the only short-jump he had, was positive
13:22:00 <clever> there was almost no way to jump backwards
13:22:00 <clever> so every time you want to go backwards, you have to jump forward say 128 bytes, repeatedly, until you hit a jump backwards 5mb marker
13:23:00 <clever> which must then cut up every function it stumbles thru, lol
13:24:00 <mrvn> first thing I would do is implement base64. :)
13:24:00 <clever> he also set himself a rule of no self modifying code
13:36:00 <zid> mmu is turing complete already but you could abuse it pretty easily to do the looping
13:36:00 <zid> so that you legitimately only had mov instructions
13:39:00 <zid> hmm how do you reset the I bit actually
13:42:00 <zid> oh nevermind, exceptions are NMIs aren't they
13:49:00 <mrvn> zid: the mmu does 0 instructions computing :)
16:06:00 <jimbzy> Good day, all.
17:27:00 <mrvn> mega.nz needs more fast caches. I'm only getting 5MB/s for the new ST show from a few days ago.
17:27:00 <mrvn> watching star.trek.strange.new.worlds.s01e01.1080p.web.X265.mkv *brb*
18:28:00 * geist yawns
18:28:00 <zid> tasuketteeee loidomaaaaan~~~
18:28:00 <geist> mrvn: not that i endorse what you're doing with mega.nz, but i did enjoy the show
18:29:00 <zid> It's called netflix password sharing, it's all the rage
18:29:00 <zid> I disapprove because he's using websites instead of private trackers
18:29:00 <geist> and generally blabbing about it online
18:30:00 <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
18:30:00 <geist> so they theoretically legitimately dont know what they're hosting
18:30:00 <zid> yea
18:30:00 <zid> I wonder what the TTL is
18:31:00 <geist> never looked into it, but i dont know precisely how they can avoid 'seeing' the URL
18:31:00 <geist> since foo/bar/baz/HASHHERE would still show up as a fetch on their servers, right?
18:31:00 <zid> don't log it, and then process the ?.. in javascript I guess
18:31:00 <geist> even if it was foo/bar/baz?HASHHERE?
18:31:00 <geist> or does stuff after ? not get sent to server?
18:31:00 <zid> it does
18:31:00 <zid> PHP exposes it as $_GET[] for example
18:32:00 <zid> a hashmap
18:33:00 <geist> so maybe there's an extension to privately have args that stay local?
18:33:00 <zid> Just don't log the reqs
18:33:00 <zid> and the server only has it in ram for a few ms
18:34:00 <geist> oh sure but my point is you dont know if they're *not* doing it
18:34:00 <zid> doesn't matter though really, they're doing it for their own legal argument benefit
18:35:00 <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
18:35:00 <geist> and they can't legitimately say 'nope we have no idea what they're doing'
18:36:00 <GeDaMo> The filename is not evidence of what the file contains :P
18:37:00 <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
18:37:00 <geist> my point is the key itself ends up in the http fetch, so you can't completely claim its 100% client side
18:40:00 <geist> also reminds me i should look more into protonmail. seems like a decent service
18:40:00 <geist> but i haven't really done the due diligence to see if they're as secure as they claim
18:50:00 <mjg> heh
18:51:00 <mjg> this makes me wonder how popular piracy is today in my home country
18:51:00 <mjg> before 2013 or so it was the only option to watch wstern stuff
18:52:00 <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
18:52:00 <mjg> that's not the word
18:52:00 <geist> yah that's super dumb. artificial segmentation of the markets based on locale specific licensing agreements is dumb
18:52:00 <mjg> how do you call it properly in english
18:53:00 <geist> heh i've never heard 'lector voice' before but it pretty instantly makes sense
18:53:00 <jimbzy> dubbing?
18:53:00 <mjg> no, dubbing having a dedicated voice actor per character
18:53:00 <mjg> is*
18:54:00 <GeDaMo> Narrator?
18:54:00 <mjg> in poland you got a person reading lines for literally everything
18:54:00 <geist> oh lector voice is worse than that? oh wow
18:54:00 <jimbzy> Wow
18:54:00 <geist> yah okay that's super bad
18:55:00 <geist> do they at least usually give you subbing? i almost always prefer to watch stuff subbed anyway
18:55:00 <mjg> you can easily get cancer if you undersatnd spoken english on top of it and hear partial words :)
18:55:00 <jimbzy> Hah
18:55:00 <mjg> today i have no idea, back when i was watching tv (so 20 or so years ago), no
18:55:00 <geist> sometimes countries will have all these rules that X percentage of stuff must be in native languag,e etc
18:56:00 <mjg> it was *really* bad man
18:56:00 <geist> and he ate people
18:56:00 <jimbzy> That sounds like America, geist. We tell people they have to learn our language because we're too dense to learn theirs :p
18:56:00 <mjg> GeDaMo: does not sound right
18:56:00 <geist> 'murica!
18:56:00 <mjg> i was about to say it's a shitty audiobook, but even those tend to have multiple voice actors
18:57:00 <mjg> shitty audiobook with visuals :-P
18:57:00 <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!
18:58:00 <mjg> i'm confident most people in .pl aged 30-40 who speak good enough english to use in practice
18:58:00 <mjg> only do it because of pirating us shows
18:58:00 <geist> jimbzy: for some reason i thought you were in canada, but then i think everyone is either n canada or uk
18:58:00 <geist> which isn't true
18:58:00 <jimbzy> Nah, I'm in Missouri, USA.
18:59:00 <mjg> i would role play being in candaa, but apparently that would mean i would have to be polite
18:59:00 <geist> missouri fuck yeah!
18:59:00 <mjg> so f-word no
18:59:00 <mjg> fuck missouri
18:59:00 <geist> mjg: yah you should role play being in boston or something
18:59:00 <mjg> apoloogies, maybe you are from here
18:59:00 <geist> then you can talk about pahking your cah
18:59:00 <jimbzy> Hah
18:59:00 <jimbzy> Wolk the dowg
18:59:00 <geist> seattle, there's not much to make fun of
19:00:00 <geist> or portlanders
19:00:00 <mjg> i can give you some lines from italians in new jersey
19:00:00 <jimbzy> Missouri is a strange state outside of the cities.
19:00:00 <geist> https://youtu.be/G72tZdjnS2A is a cute standup sketch on US accents
19:00:00 <bslsk05> 'Fred Armisen Does Every North American Accent | Standup For Drummers | Netflix Is A Joke' by Netflix Is A Joke (00:05:57)
19:01:00 <geist> jimbzy: dont drink the water!
19:01:00 <mjg> my home country is smaller than many us states and still has tons of lolo dialects
19:01:00 <mjg> i can only imagine what's going on in the scale of the entire us
19:02:00 <geist> it's not old enough for super strong dialects to have settled in, is my theory
19:02:00 <jimbzy> Yeah
19:02:00 <geist> and we definitely dont have mutually unintelligable dialects
19:03:00 <heat> how many US states are larger than poland?
19:03:00 <geist> you can definitely see on the west coast, which has less and less strong dialects since it's relatively young
19:04:00 <mjg> heat: heh, apparently only 5
19:04:00 <mjg> for strictly bigger
19:05:00 <mjg> arizona is the biggest which is smaller
19:05:00 <geist> actually this guy does a much more accurate series on us accents: https://youtu.be/H1KP4ztKK0A
19:05:00 <bslsk05> 'Accent Expert Gives a Tour of U.S. Accents - (Part One) | WIRED' by WIRED (00:21:32)
19:05:00 <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.
19:05:00 <heat> yeah
19:05:00 <heat> poland is pretty big lol
19:05:00 <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'
19:05:00 <mjg> heat: i would not say big
19:05:00 <geist> since most of the west coast is effectively midwestern 'plain' american english
19:05:00 <geist> with little tweaks
19:06:00 <jimbzy> It really is.
19:06:00 <geist> but yeah that's where you get the biggest influences in california at least, mexican influences
19:07:00 <mjg> heat: according to https://en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_area it is 69th in erms of size
19:07:00 <bslsk05> en.wikipedia.org: List of countries and dependencies by area - Wikipedia
19:07:00 <geist> mjg: population wise i think only a handful of states are close to poland though. 37mil according to google
19:07:00 <geist> so probably the usual big ones. new york, texas, california
19:07:00 <jimbzy> geist, I was actually called "racist" for my accent once and I was like "Nah, this is just the way I talk?"
19:08:00 <mjg> oh heh, australia bigger than the entire european union
19:08:00 <mjg> did not realize that
19:08:00 <geist> oh actually only california has more (39mil)
19:08:00 <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.
19:08:00 <geist> the next one down is in the 20s (texas)
19:08:00 <mjg> geist: smaller population count helps more languages though due to bigger amount of disjoint communities
19:08:00 <mjg> geist: as in not in everyday contact
19:09:00 <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
19:09:00 <geist> due to cold ass weather
19:10:00 <geist> and of course having been there a long time
19:10:00 <geist> not unique to norway of course
19:10:00 <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.
19:10:00 <geist> mrvn: yah i've been watching all the new star trek shows, but so far they've been pretty bad. Picard especially so
19:10:00 <mjg> geist: i can tell you there is a village 50km from my hometown which already speaks a highly detached dialect
19:11:00 <geist> so i'm a little more than neutrally enthusiastic about BNW
19:11:00 <heat> mjg, poland is not small in area and in population, especially wrt europe
19:11:00 <mjg> geist: you can make heads and tails of what they mean, but good luck saying anything
19:11:00 <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.
19:11:00 <jimbzy> mjg: My family arrived in North America in the 1610's and we didn't learn English until the 1950's :p
19:11:00 <mrvn> The key is a js variable in the URL that isn't send to the server
19:11:00 <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?
19:11:00 <geist> ah but i dunno right? wouldn't that be in the initial fetch?
19:11:00 <mjg> jimbzy: not particularly shocked. my grandfather spent over 20 years in chicaco and did not learn squat
19:12:00 <mjg> jimbzy: thanks to living in a de facto polish area
19:12:00 <mjg> jimbzy: i know the scale is different, but i suspect it happened in a similar manner :-P
19:12:00 <jimbzy> Yeah that's how my ancestors were. It was a small, geographically isolated French community.
19:13:00 <heat> also a lot more french immigrants
19:13:00 <mjg> oh french? that cranks it up to 11
19:13:00 <mjg> no offence. maybe you have french roots.
19:13:00 <heat> was missouri part of the north american french colonies? I think so
19:14:00 <mrvn> e.g. https://mega.nz/file/ZRgATCYI#B0HsYa-JlExfjgz6wUpvf_bMJ11a73MDq1E-TNz9K5I
19:14:00 <jimbzy> Belgian, actually, but back then I suppose it was french.
19:14:00 <geist> yah i was pretty sure that # -> is the key right?
19:14:00 <mrvn> Afaik mega only sees https://mega.nz/file/ZRgATCYI and the rest is only visible locally
19:14:00 <geist> or does # stuff explicitly not get sent?
19:14:00 <geist> that would be news to me, but i am not a web developer.
19:14:00 <heat> jimbzy, nah, dutch
19:14:00 <heat> maybe a mix?
19:14:00 <geist> easy enough to trace i guess. if # is the key that would explain how it works
19:15:00 <mrvn> geist: normaly that is the ID the browser scrolls to in the page.
19:15:00 <geist> hmmmm! maybe the # stff is in the http fetch spec
19:16:00 <geist> yep. you're right. okay mystery solved
19:16:00 <heat> nah it looks like belgium was pretty firmly in dutch control
19:16:00 <mrvn> http://localhost:1234/hash#key ==> GET /hash HTTP/1.1
19:16:00 <geist> traced it with chrome and the initial fetch is: Request URL: https://mega.nz/file/ZRgATCYI
19:18:00 <jimbzy> https://en.wikipedia.org/wiki/Missouri_French
19:18:00 <bslsk05> en.wikipedia.org: Missouri French - Wikipedia
19:18:00 <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.
19:22:00 <geist> okay now about that osdev
19:22:00 <mjg> this palce was so nice for the last half hour
19:22:00 <mjg> you had to ruin it, did not you
19:22:00 <heat> computer
19:24:00 <mjg> i was looking for a new sitcom to watch
19:24:00 <mjg> without laughtrack
19:24:00 <mjg> turns out the landscape is pretty bleak
19:24:00 <heat> you should read the ACPI spec
19:24:00 <heat> there's no laugh track there
19:24:00 <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.
19:25:00 <graphitemaster> It's not called osdev unless it comes from an isolated French community, otherwise it's just sparkling software development
19:25:00 <mjg> heat: once i almost got myself into writing a uefi loader for linux from scratch
19:25:00 <mjg> heat: not my fault though
19:25:00 <heat> do it
19:25:00 <heat> bet you won't, pussy
19:25:00 <mjg> hold my acpi spec
19:26:00 <mrvn> Specifically: What's a good way to square a 64bit number modulo N with 64bit arithmetic?
19:26:00 <mrvn> and 64bit number * one of the witnesses modulo N
19:27:00 <heat> i enjoy kernel
19:27:00 <heat> not number
19:27:00 <heat> number bad
19:27:00 <heat> memory allocation good
19:27:00 <mrvn> tried to allocate a prime sieve for 64bit numbers but I run out of address space
19:28:00 <heat> good thing riscv has support for 128 bit
19:29:00 <mjg> mrvn: just copy paste something from stackoverflow like a webdev would do
19:29:00 <heat> w3schools*
19:29:00 <mjg> also i agree with heat
19:30:00 <mrvn> So just use __int128?
19:30:00 <heat> i also agree with heat
19:30:00 <heat> mrvn, no, get a rv128 cpu
19:30:00 <mrvn> Me, myself and I object.
19:30:00 <heat> object oriented mrvn
19:31:00 <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
19:32:00 <heat> is it worth it to get a domain?
19:33:00 <heat> i feel tempted to get one
19:33:00 <mrvn> if it's toplevel, sure
19:33:00 <heat> no server though :/ so i'm kinda limited
19:33:00 <mrvn> https://dry.heat/
19:45:00 <geist> stow that shit Hudson
19:46:00 <GeDaMo> I'm Hicks, he's Hudson :P
19:49:00 <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
19:49:00 <geist> could just be reseating the card was sufficient
19:49:00 <mrvn> did you try putting it back in the first slot?
19:50:00 <geist> not yet. probably will wait another day so it's at least 2x the usual MTBF
19:50:00 <mrvn> Just removing and plugging it back in might have rubbed off some oxidation.
19:51:00 <geist> yah exactly. really i should have done that first: just reseated everything
19:51:00 <geist> if it magically started working then there was something like that and move on
19:53:00 <mrvn> got any contact spray?
19:54:00 <zid> I also failed the "should have just reseated it" test last week
19:54:00 <zid> my monitor 'died' at random during use
19:54:00 <zid> turns out the port was a little.. spring loaded, and had ejected the hdmi cable like a gun
19:56:00 <geist> huh interesting
19:57:00 <jimbzy> I used to get issues like that with ISA cards.
19:57:00 <zid> The usual retaining mechanism of 'bit of bent steel' to try keep the plug friction-fit
19:57:00 <zid> combined with the cable only being 85% of the way in
19:58:00 <zid> -> port is trying to spring the cable out of the port
19:58:00 <zid> you'd know exactly what I meant if you felt it
20:02:00 <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.
20:02:00 <jimbzy> Pavlov's landscaper.
20:03:00 <geist> yah also interesting that this is an x1 video card now plugged into an x16 slot. which doesn't hold it at all
20:03:00 <geist> especially since it can't get to the clip at the end of the slot
20:03:00 <zid> I hope you have a lego-man to hold the end up
20:03:00 <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
20:04:00 <geist> liek an x4 10gbe
20:04:00 <zid> aren't all video cards 1x
20:04:00 <heat> no they're x16
20:04:00 <zid> up to
20:04:00 <geist> right. most video cards you find are x16 width physically
20:04:00 <zid> they will work fine on, as low as 4 imperically
20:04:00 <zid> but I assumed 1x would also work
20:05:00 <geist> right, but then they physically wont plug into an x4
20:05:00 <zid> 1x slots all have open backs on my board
20:05:00 <geist> that's the problem. it's a physically x1 card, so it physically plugs into everything
20:05:00 <geist> ah well nice for you. mine do not
20:05:00 <zid> nothing a dremel can't fix
20:05:00 <geist> well if there's other shit in the way actually yes
20:05:00 <geist> probably a function of your server/workstation style mobo
20:06:00 <zid> actually does 1x even need the open back, isn't there a notch
20:06:00 <zid> where the 'end' would be anyway
20:06:00 <zid> *needs to find a pci-e card real quick*
20:06:00 <geist> ah i think no. i think it just extends on
20:06:00 <geist> yah no. the part that's notched off is i think common to everything maybe?
20:07:00 <geist> or anyway that implies the plastic around the slot would also have to be narrower than the notch
20:07:00 <geist> which is fairly narrow
20:07:00 <zid> okay yea they only have one notch, boo
20:08:00 <zid> so you'd need to dremel out a regular 1x slot
20:08:00 <zid> https://user-images.githubusercontent.com/518023/99198975-41f6b200-279c-11eb-86e9-ca7dabc5cfe7.jpg or whip out your soldering iron and swap it for one of these
20:08:00 <geist> but notice that whats just off the end of that is also free
20:08:00 <geist> you h ave to not populate what's off the end of the board with caps or chips or whatnot
20:08:00 <geist> and so basically they design it that way in your case
20:09:00 <zid> all my gpus have quite the gap between the fingers and the actual pcb
20:09:00 <zid> because of southbridges often being in the way
20:10:00 <zid> https://pbs.twimg.com/media/FRwd78VXEAc5CPj.jpg This is now my canonical motherboard reference pic
20:10:00 <geist> yah the i can yell at the cards when i plug them in
20:10:00 <zid> nothing on the board above the height of a pci-e slot, nothing on the card lower than the top of the fingers
20:10:00 <geist> get in the fucking motherboard evga
20:11:00 <zid> I don't even know what socket a z690 is, but I want one in a picture frame
20:12:00 <geist> so there's osme other changes as a result of moving the card from one of the x1 slots to x16
20:12:00 <geist> i think the x16 is right on the ryzen, whereas the x1 is attached to the southbridge
20:12:00 <zid> at least amd gives you lanes
20:12:00 <zid> on intel they don't even have enough lanes on the desktop cpus to let you plug anything but a gpu in
20:13:00 <zid> I have three 16x slots off the cpu, anything recent is 20 lanes total, 16 to top slot, 4 to integrated nic/sata/etc
20:14:00 <heat> aren't they allocating most of it towards m.2 nowadays?
20:14:00 <zid> you wish
20:14:00 <zid> you're not allowed an ssd on a modern intel desktop
20:14:00 <zid> the southbridge just plexes it with all the other garbage
20:14:00 <zid> and those plex chips aren't cheap and make the board cost $400 :p
20:15:00 <heat> you need to use Intel(r) Optane(tm)
20:18:00 <geist> oh interesting, this x1 vid card is actually a radeon HD 5430 mobile chip
20:18:00 <geist> i had gotten it for $5 at a surplus store, so wasn't really sure what it was
20:19:00 <heat> a mobile chip as a separate card?
20:19:00 <heat> very unusual
20:19:00 <geist> yah, or at least that's what lspci decodes it as
20:19:00 <geist> but then again, x1 vid cards are also pretty rare
20:19:00 <zid> sounds like a startech special
20:20:00 <geist> basically
20:20:00 <geist> anyway have been suspecting it since i added it to the server when adding a 10gbe card a while back.
20:20:00 <geist> so was thinking this was the source of my instability
20:20:00 <zid> I paid startech a lot of money to solder me a via usb chip to a pci-e connector
20:23:00 <jimbzy> I just ordered some new toys. A new multimeter, a USB logic analyzer and a TL866II Plus.
20:23:00 <geist> noice
20:24:00 <jimbzy> I need a 6502-based microcomputer in my life.
20:25:00 <mjg> you guys really like talking shop, huh
20:27:00 <geist> you're just now figuring this out?
20:27:00 <zid> to be honest, we mainly talk about cats and evangelion
20:27:00 <jimbzy> Yeah, for about the last 20 years or so :P
20:31:00 <mrvn> my cat has more features than yours
20:32:00 <mjg> geist: just checking
20:32:00 <zid> My cat contains the soul of its death mother and has armor plates to limit its power
20:32:00 <zid> s/th/d
20:32:00 <Maka_Albarn> Besides having a static load address for applications, is there really any benifit to a higher-half kernel for 32-bit systems?
20:32:00 <geist> vs what?
20:33:00 <Maka_Albarn> versus a regular lower-half kernel
20:33:00 <geist> having the two address spaces swapped? kernel at bottom?
20:33:00 <zid> not sure what higher half has to do with static load addresses
20:33:00 <zid> lower-half is irregular
20:33:00 <Maka_Albarn> Read the listed advantages:
20:33:00 <Maka_Albarn> https://wiki.osdev.org/Higher_Half_Kernel
20:33:00 <bslsk05> wiki.osdev.org: Higher Half Kernel - OSDev Wiki
20:33:00 <mjg> did anyone do lower half, exluding for lulz perhaps?
20:33:00 <mrvn> pure convention
20:33:00 <heat> sortie
20:33:00 <geist> if you mean just between high and low, on x86 not really. you can do either
20:33:00 <geist> it's convention
20:34:00 <Maka_Albarn> ah. thank you.
20:34:00 <geist> some arches mandate it however, so in general it makes sense to follow the convention
20:34:00 <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
20:34:00 <zid> lower half probably makes vm86 really really difficult
20:34:00 <geist> BeOS, for example, had them inverted
20:34:00 <geist> probably other kernels that did too, but that's the only one i know of off the top of my head
20:34:00 <mjg> quite frankly i autocorrected "higher half" to having it mapped to begin with
20:34:00 <mrvn> zid: why? you plan to use the first 1MB?
20:35:00 <Maka_Albarn> vm86 is completely under 1MB, my kernel is loaded at 1MB, so the vm86 shouldn't be a problem
20:35:00 <mjg> you know what would be funny
20:35:00 <mjg> kernel using 2G in the middle
20:35:00 <zid> mrvn: you're going to add checks for that to your is_kernel()? gross
20:35:00 <zid> I'd rather check the sign bit instead of a complicated set of conditions
20:35:00 <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
20:35:00 <heat> zid, ye cant
20:35:00 <heat> the new amd address tagging disallows that
20:36:00 <geist> execept obviously modern machines you pay a penalty for non zero based segments
20:36:00 <mrvn> heat: (addr << TAG_SIZE) < 0
20:37:00 <heat> they broke the canonicality of the higher address bits and linux kernel people are pissed
20:37:00 <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)
20:37:00 <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
20:37:00 <Maka_Albarn> hmm...
20:38:00 <Maka_Albarn> what about a modular kernel where the modules are loaded as higher-half, but the core system is lower-half?
20:38:00 <heat> why
20:38:00 <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.
20:38:00 <geist> yeah why is the main thing
20:38:00 <geist> also 64bit makes most of these decisions completely obsolete
20:38:00 <mrvn> (assuming the bootloader always goes to lower half)
20:39:00 <geist> since functionally speaking modern 64bit machines lay out their virtual addresses pretty mnuch the same way
20:39:00 <geist> though i guess on x86-64 you can still put kernel at 0 and user space at 0xfff8.0000.0000.0000
20:39:00 <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
20:39:00 <heat> yeah but your codegen will be bad
20:39:00 <geist> er 0xffff.8000.0000.0000
20:39:00 <zid> when does mcmodel=kernel actually do anything?
20:39:00 <mrvn> I wonder if a system that has physica memory (only) at the higher half would go with lower half kernels.
20:39:00 <geist> zid: when zero or 1 or sign extending 32bit constants
20:39:00 <zid> so never?
20:40:00 <geist> a lot. actually
20:40:00 <zid> everything is PIE and ASLR and stuff these days in my world
20:40:00 <heat> except when it's not
20:40:00 <mrvn> zid: mcmodel=kernel has addresses from -2G to 0 instead of 0 to 4G
20:40:00 <geist> but note it assumes that code is within -2GB i think so in that case the sign extension is nice
20:40:00 <zid> I've not used a constant address for anything in a very long time in a program
20:40:00 <heat> and when it's not, mcmodel=kernel/small is good
20:41:00 <geist> okay. well if you are okay with the cost then full pie is fine
20:41:00 <zid> I didn't even think there was a cost
20:41:00 <zid> riprel is freeeee
20:41:00 <geist> not entirely no
20:41:00 <heat> nothing is free
20:42:00 <mrvn> geist: what cost? doesn't it just give linker errors when you exceed the mcmodel address range?
20:42:00 <geist> it's very easy on x86 to encode say a sign extended 32bit fixed address in an instruction
20:42:00 <zid> if nothing is free, everything is free :P
20:42:00 <zid> that's what riprel already does though geist
20:42:00 <geist> right, but you can't use that in all contexts i believe
20:42:00 <geist> so you end up having to compute address with lea and then use it, i believe
20:42:00 <geist> but honestly idont want to think about it right now
20:43:00 <zid> oh right maybe a few encodings go missing, but it's not like movsx has a lot of encodings either
20:43:00 <geist> there's reasons for it. whether or not it matters is <shrug>
20:43:00 <zid> I bet riprel has more because it's just part of sib, compared to sign extention
20:43:00 <geist> i mean we're compiling zircon in basically pic mode because of KASLR
20:43:00 <geist> and i think <shrug> it technically costs something but so it goes.
20:44:00 <mrvn> heat: if you have mcmodel=large than every function call will be 64bit.
20:44:00 <geist> i do know that fixed address non pic, large (or is it huge) mcmodel is terrible and you should avoid
20:44:00 <geist> yah thatssss bad
20:44:00 <heat> mrvn, yes
20:44:00 <geist> and furthermore i dont think it's well tested since stuff doesn't use it
20:44:00 <zid> how does that work? there's no absolute call on x86
20:44:00 <heat> movabs $symbol, %reg
20:44:00 <zid> oh, lovely
20:44:00 <heat> call (%reg)
20:44:00 <geist> yah play with godbolt a bit and you'll see
20:45:00 <mrvn> which is like 3 times the size
20:45:00 <zid> I bet in practice it's not like.. terrible
20:45:00 <geist> also pic is equally bad because the riprel cant encode offsets as large as large mode expects
20:45:00 <geist> so i think it has to do something like get the pc and do the 64bit add manually
20:45:00 <zid> thunks yo
20:46:00 <geist> since i think large mode also means sizeof(code) > 2GB as well
20:46:00 <zid> combining it with pic sounds amazing
20:46:00 <geist> but yeah the more i think abouti t, i think mcmodel=kernel mostly applies for non PIC modes
20:46:00 <geist> because then you can encode kernel addrfesses with a 32bit sign extended thing
20:47:00 <zid> right it only really 'does' anything with 64bit absolute addresses that you can then safely truncate down
20:47:00 <zid> if everything is relative 32bit addresses already it does nothing
20:47:00 <geist> something like that
20:47:00 <zid> I don't think you can convince it that pointers are 32bit at all which would be fun
20:47:00 <heat> yeah I think mcmodel options make little to no difference when compiling with PIC or PIE
20:47:00 <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
20:48:00 <geist> but i can't tell you what it is offhand
20:48:00 <zid> tack some __attribute__((small)) onto some struct and it movsx's the pointers in it from 32bit
20:48:00 <geist> this is a case where 30 minutes with godbolt will tell you a lot
20:48:00 <zid> that'd be neat
20:48:00 <zid> that's why I was confused geist
20:48:00 <geist> but frankly i spend most of my brain cells on arm64 and riscv nowadays if i can avoid it
20:48:00 <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
20:48:00 <mrvn> This discussion makes me want a x86_32 kernel model.
20:49:00 <geist> x86 is just like slogging into a C++ war. it's a rich battlefield, but meh you just feel dirty
20:49:00 <heat> we need x86-64 2 the sequel
20:50:00 <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
20:50:00 <geist> ie, yeah maybe the codegen is worse but then the cpu is tuned for it so it eats it up, etc
20:50:00 <zid> and.. microop caches means codegen is not what codegen says it is
20:51:00 <zid> so all you're really eating is L1 miss effects etc
20:51:00 <geist> interesting, true, but just harder to think about unless it's really important
20:51:00 <zid> I bet that movabs rax; call rax case is actually like.. really incredibly hard to measure a performance loss for
20:51:00 <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>
20:51:00 <zid> unless the predictor just can't handle it
20:51:00 <heat> are you a hacker geist
20:52:00 * geist HAX
20:52:00 <zid> He's a VAX actually
20:52:00 <zid> Personally, I am anti-vax
20:52:00 <geist> yah slowly working on this FAT driver
20:52:00 <zid> I don't think our children should be exposed to it
20:52:00 <geist> restructuring it so it's ready for the next phase: write support
20:53:00 <heat> yoo i just had the best idea
20:53:00 <heat> sancov support
20:53:00 <heat> i need that
20:53:00 <zid> murder all the children fi- oh
20:53:00 <heat> zid, shhhh
20:54:00 <heat> don't tell everyone my plan B
20:54:00 <zid> Actually Plan B is to murder them before they're children
20:54:00 <zid> You're thinking of Preperation H
20:57:00 <clever> i'm in the mood to write an ethernet driver today!
20:57:00 <clever> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/net/ethernet/broadcom/genet/bcmgenet.c
20:57:00 <bslsk05> github.com: linux/bcmgenet.c at rpi-5.10.y · raspberrypi/linux · GitHub
20:57:00 <clever> so far, ive confirmed that the pi400 has a version 5 genet, which supports 64bit dma
20:57:00 <clever> there appears to be 256 slots each for rx&tx, where you set the flags, length, and 64bit addr
20:58:00 <clever> and flags includes start/end of packet, so scatter-gather is done by just filling in multiple consecutive slots
20:58:00 <clever> the length field is only 12bits, so 4095 bytes max per fragment
20:59:00 <clever> and a forum thread claims the hardware supports 16kb jumbo frames
21:00:00 <geist> makes sense. where are the slots? in memory i assume?
21:00:00 <clever> in mmio space
21:00:00 <geist> interesting, usually that's in ram itself
21:00:00 <clever> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/net/ethernet/broadcom/genet/bcmgenet.c#L3773-L3775
21:00:00 <geist> so basically 512 pointers to a descriptor?
21:01:00 <bslsk05> github.com: linux/bcmgenet.c at rpi-5.10.y · raspberrypi/linux · GitHub
21:01:00 <geist> i dont want to read it
21:01:00 <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
21:01:00 <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?
21:02:00 <clever> the start/end of packet flags are listed as common
21:02:00 <clever> and linux drops any packet that is not both the start and end
21:02:00 <geist> makes sense, fairly straightforward
21:02:00 <heat> why does that sound like the rtl8168
21:02:00 <clever> so a packet can span multiple buffers, but linux doesnt allow it
21:02:00 <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
21:02:00 <heat> ye
21:02:00 <clever> some versions of genet are 32bit only, so the addr_hi field is missing
21:03:00 <geist> that's a lot of latches to hold all of that
21:03:00 <clever> its probably just blockram at that point?
21:03:00 <geist> yah probably
21:03:00 <clever> comments mention that writes to that area can take several 100 nanoseconds
21:03:00 <clever> and if the host is built in 32bit mode, it skips writing to addr_hi, to save a write
21:03:00 <geist> right, that'd be the usual reason not to do that
21:04:00 <clever> if your staying within the lower 4gig, then each packet tx requires 2 x 32bit writes
21:04:00 <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
21:04:00 <clever> exactly
21:04:00 <clever> but the hw has a max buffer size of 4095 bytes (12bit length field)
21:05:00 <geist> sure but you could queue up say all 1k or 2k buffers, and then let the packet split across them
21:05:00 <clever> so i'm not sure how linux will deal with jumbo frames over that
21:05:00 <heat> it won't
21:05:00 <geist> that's why i was saying there's a SOF EOF bit probably, because then you just read forward and use subsequent buffers
21:05:00 <clever> yep
21:05:00 <geist> and then construct a split skbuf for it and pass that up the stack. should handle that
21:05:00 <clever> the hw allows that, but linux doesnt
21:05:00 <heat> nah, no split skbuf
21:05:00 <geist> not sure. i'd be highly surprised if linux doesn't allow a split RX buffer
21:06:00 <heat> you can't pass NIC rx buffers into the network stack
21:06:00 <clever> more, that the linux implementation of the driver doesnt allow it
21:06:00 <clever> the author choose to not support it
21:06:00 <heat> they allocate an skbuff and copy stuff in
21:06:00 <geist> huh that's really odd. i'd think any sane net stack would lety ou do that on TX and RX
21:06:00 <clever> assuming i'm reading the code right
21:06:00 <heat> a packet can get stuck in processing for a lot of time
21:07:00 <heat> also, rx'd packets go directly to the queue that recvmsg reads from
21:07:00 <geist> but i guess maybe they decided that you pay the cost here at the transistion from nic to stack rather than elsewhere
21:07:00 <clever> heat: you could always change the addr in the rx ring, but that complicates management more
21:07:00 <geist> my general knowledge of these things is based on BSD style mbufs which i assume also did this
21:07:00 <heat> you could realloc pages but do you really get that much performance from that?
21:07:00 <geist> but... maybe not?
21:07:00 <clever> there is also an optional 64 byte status message, that gets prepended to the packet (for both tx and rx)
21:08:00 <clever> which is involved in hw checksumming
21:09:00 <geist> makes sense. fairly standard
21:09:00 <heat> https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/realtek/r8169_main.c#L4535
21:09:00 <bslsk05> elixir.bootlin.com: r8169_main.c - drivers/net/ethernet/realtek/r8169_main.c - Linux source code (v5.17.5) - Bootlin
21:09:00 <heat> there's an example of skbuff allocation on RX
21:10:00 <geist> there's only so many ways to do this really. most designs have pretty much circled in on a similar thing
21:10:00 <clever> this is basically the same as that ancient 100mbit pci nic i looked at years ago
21:10:00 <clever> they just expanded it from 4 dma buffers to 256 dma buffers
21:10:00 <clever> and a packet can now span several buffers
21:11:00 <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
21:11:00 <heat> in fact they don't seem to handle packets that span multiple buffers here either
21:11:00 <heat> huh
21:11:00 <geist> something that offloads even more cpu
21:11:00 <clever> the next thing i need to investigate, is how to enable rx
21:11:00 <clever> and deal with irq's
21:11:00 <geist> heat: e1000e might be interesting to look at, if there's a driver that does the full monty its that one
21:11:00 <heat> voodoo
21:12:00 <geist> i do remember the e1000 rx descriptors were a little surprising but makes sense in retrospect
21:12:00 <heat> the e1000 is not fun to look at
21:12:00 <heat> there are multiple types of descriptors in the e1000
21:12:00 <geist> you create a ring of power of N descriptors, and they're *all* power of N size
21:12:00 <geist> ie, 256, 512, 1024, 2048, etc
21:12:00 <clever> /* Always use RX_BUF_LENGTH (2KB) buffer for all chips */
21:13:00 <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
21:13:00 <clever> thats half of the buffer the hw reg implies its capable of
21:13:00 <geist> here's why i think e1000 has to deal with large ass packets: TSO
21:13:00 <clever> ah, neat
21:13:00 <geist> the hardware supports the hell out of it, so presumably it's frequently handing the stack up to 64k reassembled packets
21:13:00 <heat> the rtl8168 also has it I think
21:13:00 <clever> there is a performance counter i saw in genet, with a label of `RO Rx/Tx 4096-9216 bytes packet`
21:14:00 <clever> i think its also doing power of 2 based buckets for at least the perf counters
21:14:00 <geist> you effectively run the nic as if it had a MTU of 64k and let it disassemble/reassemble packets
21:14:00 * Maka_Albarn yawns
21:14:00 <Maka_Albarn> still not fully awake
21:14:00 * geist hunts around for the large trout
21:15:00 <heat> fun fact: qemu's virtio-net doesn't support any offloading
21:15:00 <heat> the e1000 does though
21:15:00 <geist> what kind of offloading?
21:15:00 <heat> TSO, checksum offloading
21:16:00 <clever> ok, found the irq handler, now to find the irq#.....
21:16:00 <geist> TSO no, but i do remember there's at least a feature bit for checksum
21:16:00 <heat> there's no TSO? I think there is, but I might be wrong
21:16:00 <geist> for virtio-net that is
21:17:00 <heat> oh yeah it technically supports all of that
21:17:00 <heat> but the feature bits are never enabled
21:17:00 <clever> one table lists them as irq 29 and 30
21:17:00 <geist> of course checksum offloading for a virtual nic is sort of moot
21:17:00 <clever> oh, that reminds me of a fun bug i found on the pi2's usb nic
21:17:00 <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
21:18:00 <clever> and then relying on usb checksums to carry the data intact
21:18:00 <Maka_Albarn> I don't really bother with vms. I just use a spare laptop. need to get a GDB stub integrated though....
21:18:00 <clever> but, because my usb phy was mis-configured, it silently corrupted packets, and linux didnt re-check the tcp/ip checksums
21:18:00 <heat> Maka_Albarn, that seems insane
21:18:00 <heat> you definitely should
21:18:00 <Maka_Albarn> heat: lol
21:19:00 <heat> 99.9% of my deving is in VMs
21:19:00 <heat> s/in/for/
21:19:00 <Maka_Albarn> need to upgrade my malloc/free system and set up serial comms first.
21:19:00 <clever> oh, does qemu already support genet?
21:19:00 <heat> no?
21:19:00 <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
21:20:00 <clever> heat: correct!, no trace of genet in qemu master
21:20:00 <geist> seems to be what it's advertising to me now. i think i print all the flags
21:20:00 <heat> hmmmmmmm
21:20:00 <clever> ok, now lets see if i can get any irq out of this...
21:22:00 <heat> geist, do you have bits 0, 7, 8 and 10?
21:23:00 <heat> i check for those for csum, tso4, tso6 and ufo
21:23:00 <geist> https://github.com/littlekernel/lk/blob/master/dev/virtio/net/virtio-net.c#L44 yeah looks like i have the full suite
21:23:00 <bslsk05> github.com: lk/virtio-net.c at master · littlekernel/lk · GitHub
21:23:00 <geist> there's a printf a bit lower
21:23:00 <geist> i wonder if it's different if bridging or not
21:26:00 <clever> ok, so bootmain.elf isnt using the genet irq, it must be in polled mode
21:26:00 <geist> ah hah yes: virtio-net host features (0x39bfffe7): CSUM GUEST_CSUM CTRL_GUEST_OFFLOADS MAC GSO GUEST_TSO4 GUEST_TSO6 GUEST_ECN GUEST_UFO HOST_TSO4 HOST_TSO6 HOST_ECN HOST_UFO MRG_RXBUF STATUS CTRL_VQ CTRL_RX CTRL_VLAN GUEST_ANNOUNCE CTRL_MAC_ADDR
21:26:00 <geist> that's if i'm running it as a tun/tap
21:26:00 <clever> i'll just blindly assume 29/30 is right, and turn em on...
21:26:00 <geist> so makes sense. when using it for user networking it seems to not bother doing TSO or whatnot, which kinda makes sense maybe
21:28:00 <clever> LK_INIT_LEVEL_PLATFORM feels about right for an ethernet driver?
21:30:00 <geist> yah or call it directly from the platform hook
21:30:00 <geist> theres a branch that revises the way the net stack gets ethernet registration set up that'll be more natural but it'll go in that direction
21:30:00 <clever> i'm currently making it optional, so that makes it a bit more complex
21:30:00 <geist> nic finds itself, registers with net stack, net stack starts dhcp, etc
21:30:00 <geist> vs the nonsense we have here now
21:31:00 <clever> platform/bcm28xx/genet.c:125:21: error: expected ‘)’ before ‘&’ token
21:31:00 <clever> LK_INIT_HOOK(genet, &genet_init, LK_INIT_LEVEL_PLATFORM);
21:32:00 <clever> maybe it cant match the name of the STATIC_COMMAND_END(genet)?
21:32:00 <geist> lets take it to #lk
21:33:00 <heat> the smallest of kernels
21:55:00 <heat> geist, how does zircon export coverage information?
21:55:00 <geist> i have no clue
21:55:00 <heat> I'm assuming you do cuz of syzkaller at least
21:55:00 <mrvn> On sockets can one combine MSG_PEEK + MSG_TRUNC in recv to find out how many bytes are buffered for a socket?
21:56:00 <heat> yes
21:56:00 <geist> heat: sure but i personally have no clue
21:56:00 <mrvn> recv(sock, NULL, 0, MSG_PEEK | MSG_TRUNC)
21:56:00 <heat> yes that looks fine
21:56:00 <mrvn> like that?
21:56:00 <heat> you also have an ioctl
21:56:00 <heat> FIONQREAD iirc
21:56:00 <heat> FIONREAD*
21:58:00 <heat> geist, found it: https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0078_kernel_coverage_for_fuchsia_fuzzing
21:58:00 <bslsk05> fuchsia.dev: RFC-0078: Kernel Sanitizer Coverage for Fuchsia Fuzzing
21:58:00 <geist> cool
21:59:00 <heat> i want to see if I can get some fuzzing
21:59:00 <heat> inspired by some guy who just fed afl into AF_NETLINK and fuzzed that
22:00:00 <heat> syzkaller would be ideal though
22:04:00 <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
22:09:00 <heat> yup
22:09:00 <heat> my platform is sufficiently similar to linux or one of the BSDs, i imagine i'll need to do something similar to them
22:40:00 <mjg> there is bsd support for it
22:40:00 <mjg> it can't be that hard then
22:41:00 <mjg> i mean at least in terms of time invistment
22:41:00 <mjg> investment even
22:41:00 <mjg> and by bsd i mean free, net and open all have it
22:41:00 <mjg> so...
22:42:00 <geist> yah i think the main trouble weith zircon was it was sufficiently foreign at the syscall layer it took some more work
22:42:00 <geist> based on general assumptions of posixness, how handles work, etc
22:43:00 <geist> gosh you know one feature i wish i had from rust is redeclaring a variable as const in the middle of a function
22:43:00 <geist> that's really handy
22:51:00 <mjg> hm
22:52:00 <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"
22:53:00 <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
22:53:00 <mjg> and i can't add const without compilation breaking in aleph0 places
22:54:00 <mjg> the standard c cumbersome fuckery would be to wrap it into an opaque struct and patch all places to use an accessor
22:56:00 <heat> love standard c cumbersome fuckery
22:57:00 <heat> it's part of the C experience
22:58:00 <mjg> #ifndef FUCKING_HEADER_H
22:58:00 <mjg> i only actively notice it when i can't fix it up in 1 minute, like with the above
22:58:00 <heat> i don't fuck headers but i also dont kink shame
22:58:00 <heat> you do you homie
22:58:00 <jimbzy> If you're not having stress dreams about memory allocation then you're not getting your money's worth out of C.
22:58:00 <mjg> thanks, i appreciate your opennens
22:59:00 <heat> jimbzy, goto out;
22:59:00 <geist> ahaha
22:59:00 <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
22:59:00 <geist> that one goes into some sort of osdev quotes file
23:00:00 <jimbzy> Yeah, no shit.
23:02:00 <heat> if you haven't reinvented object oriented programming in C, you're not doing it right
23:03:00 <mjg> i would argue you are doing c right if you shit on the language
23:03:00 <heat> C++ is bad but struct file_operations is peak programming
23:06:00 <jimbzy> Sometimes you just have to reach around the Lexan, run the compiler and hope for the best.
23:39:00 <geist> yay created my first file