[itchyjunk] has quit [Remote host closed the connection]
smeso has quit [Quit: smeso]
sdfgsdfgDropBear has joined #osdev
smeso has joined #osdev
mahmutov has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
freakazoid12345 has quit [Ping timeout: 268 seconds]
sm2n_ has quit [Read error: Connection reset by peer]
sm2n_ has joined #osdev
ElectronApps has joined #osdev
mahmutov has quit [Ping timeout: 252 seconds]
devcpu has quit [Quit: leaving]
transistor has joined #osdev
devcpu has joined #osdev
<klange>
I appear to have made a quick recovery from the after-effects of the second dose. Made it up to 37.8˚ last night but have cooled back down and just have the sore arm again.
xenos1984 has quit [Quit: Leaving.]
<vdamewood>
klange: Personal body temperature or ambient temperature?
<geist>
yeah that was basically my experience
<geist>
it hits you fast and then dissapears pretty quickly
Brnocrist has quit [Ping timeout: 268 seconds]
<klange>
vdamewood: Personal body temperature ;) I think it was around 26 for most of yesterday, but I was only out in the morning to get to and from my appointment.
<klange>
Spent the afternoon in bed with one of my cats, had a terrible night of not being able to sleep, but by around 8am I was peachy.
<vdamewood>
26?!
<klange>
A perfectly reason and frankly nice temperature for Tokyo? It's 30 today and ugh.
<klange>
reasonable*
<vdamewood>
Oh, ambient.
<klange>
I think it would be rather problematic if the ambient were 37 and body temperature were 26
<vdamewood>
Yes.
<vdamewood>
err Hep
<vdamewood>
Yep
<vdamewood>
Dammit
jjuran has quit [Ping timeout: 268 seconds]
sdfgsdfgDropBear has quit [Quit: sdfgsdfgDropBear]
<heat>
paracetamol + lots of ice really helped with the vaccine's effects for me, barely had any fever
<heat>
although mine was a single dose vaccine (janssen)
<vdamewood>
I got Moderna and just toughed it out. I was tired for three days.
sdfgsdfgDropBear has joined #osdev
<vdamewood>
So, I hear some big osdever is going to release a new version of their OS tomorrow.
<heat>
templeos 2 was confirmed?
<vdamewood>
That project is as dead as its author.
<klange>
Sortix 1.1 is finally coming out?
<kingoffrance>
klange's cat hit some keys, and there is a new fork
<klange>
I swear ToaruOS 2.0 will happen before the end of the year.
<vdamewood>
Which year?
sdfgsdfgDropBear has quit [Quit: sdfgsdfgDropBear]
<klange>
This year! Really it's just me dragging my feet. I could release it as-is and it would be fine, but there's just so much more I want to do...
<heat>
I can't make myself release a 1.0 because I'll never be satisfied with what I've done
<heat>
until I singlehandedly reimplement linux 2.6 I guess lol
<vdamewood>
I haven't released 1.0 because I don't have a kernel, compiler, shell, or even a bootloader.
<kingoffrance>
do you plan a compiler?
<kingoffrance>
or you mean you havent ported one?
<vdamewood>
I meant either, but I plan on porting clang.
<heat>
right now I'm working on revamping the fs writeback code to be 1) stable 2) fast and all the concepts are super unclear to me and I'm starting to get discouraged
<heat>
i sort of have a decent idea of how things work in linux, which is a good start, but all the locking and synchronisation that is needed is still horribly unclear to me
<heat>
also, fun thing I found out: in Linux, a disk block read from /dev/sdaX and a page read from the corresponding file can have different contents, even after a sync
sdfgsdfgDropBear has joined #osdev
sdfgsdfgDropBear has quit [Client Quit]
jjuran has joined #osdev
jjuran has quit [Remote host closed the connection]
jjuran has joined #osdev
heat has quit [Ping timeout: 246 seconds]
<klange>
ToaruOS 2.0 has... a network stack that is technically more capable than the one it replaced in 1.x, most of the drivers from 1.x with only a handful of network chipsets no one cares about missing (everything worth using supports an e1000 or e1000e)...
<zid>
even I support e1000 and I'm a fucking idiot
<klange>
SMP is working, stable, and I dare say actually usable. The ports collection is mostly just missing Python because I'm still debating if I want to package 3.6 again (last version that doesn't have strong pthread requirements) or finish up the missing pthread shit to port a newer version...
<klange>
We've got a Doom (with sound), the Quake port is running great, I even managed to bring back the MuPDF port that was last built for the 1.2.x Newlib ABI...
<klange>
It magics it from a geo IP service, but there's some envvars you can force in ~/.yutanirc - not quite standard stuff, but TZ_OFFSET is seconds from UTC and I had one for the abbreviation I think...
<zid>
your geo ip service is incorrect then :P
<klange>
What did it give?
<zid>
CEST
<zid>
instead of BST
<klange>
Ah, well, darn.
<klange>
"export TZ_OFFSET=3600" in ~/.yutanirc and then log out and back in, it's janky as all hell but it's better than the complete lack of any concept of timezones from previous versions
<klange>
Also the list of abbreviations is like a half dozen ones I knew off hand :D
<klange>
Time to d/c from my screen session and check my fuel indicator~
<klange>
bye o/
sdfgsdfgDropBear has quit [Quit: sdfgsdfgDropBear]
moon-child has quit [Quit: !]
moon-child has joined #osdev
bradd has quit [*.net *.split]
orthoplex64 has quit [*.net *.split]
junon has quit [*.net *.split]
vancz has quit [*.net *.split]
terrorjack has quit [*.net *.split]
amine has quit [*.net *.split]
acidx has quit [*.net *.split]
gorgonical has quit [*.net *.split]
fkrauthan has quit [*.net *.split]
buffet has quit [*.net *.split]
stux|away has quit [*.net *.split]
m5zs7k has quit [*.net *.split]
DanDan has quit [*.net *.split]
lg has quit [*.net *.split]
X-Scale has quit [*.net *.split]
z_is_stimky has quit [*.net *.split]
ZetItUp_ has quit [*.net *.split]
ckie has quit [*.net *.split]
rb has quit [*.net *.split]
mniip has quit [*.net *.split]
MiningMarsh has quit [*.net *.split]
Burgundy has joined #osdev
mniip has joined #osdev
X-Scale has joined #osdev
buffet has joined #osdev
vancz has joined #osdev
DanDan has joined #osdev
stux|away has joined #osdev
junon has joined #osdev
MiningMarsh has joined #osdev
bradd has joined #osdev
ZetItUp_ has joined #osdev
orthoplex64 has joined #osdev
lg has joined #osdev
rb has joined #osdev
m5zs7k has joined #osdev
fkrauthan has joined #osdev
amine has joined #osdev
acidx has joined #osdev
z_is_stimky has joined #osdev
terrorjack has joined #osdev
ckie has joined #osdev
gorgonical has joined #osdev
terrorjack has quit [Max SendQ exceeded]
terrorjack has joined #osdev
GreaseMonkey has joined #osdev
GeDaMo has joined #osdev
<sortie>
klange, oh man, I actually did resume Sortix work this year and thought I could finish 1.1 but uh it's October and uh the network stack still isn't merged
<mjg>
:)
<j`ey>
sortie: just merge it :P
Kerum has joined #osdev
<mjg>
do you happen to have a custom bgp daemon?
<Kerum>
if an ISR for an interrupt X is in privilege ring 0, should the interrupt descriptor for the interrupt X have a DPL of 0 or 3?
dennis95 has joined #osdev
<zid>
that's a sentence splice and a half
<zid>
"If your ISR is ring0, should it be ring0 or ring3?"
<zid>
Is how that reads to me
<Kerum>
well im asking because i saw someone use a kernel code segment and a DPL of 3 in an interrupt descriptor, which was in conflict with what osdev wiki says
<Kerum>
if i could think of a privileged instruction to put in the interrupt handler i could check
<Kerum>
maybe i could "mov %cr0, %eax; mov %eax, %cr0"
<zid>
I thought it was about the entry condition, but I don't read the idt pages much
junon has quit [Ping timeout: 252 seconds]
<zid>
The processor checks the DPL of the interrupt or trap gate only if an exception or interrupt is generated with an
<zid>
INT n, INT3, or INTO instruction.4 Here, the CPL must be less than or equal to the DPL of the gate.
<zid>
his
<zid>
interrupt to access critical exception handlers, such as the page-fault handler
<zid>
restriction prevents application programs or procedures running at privilege level 3 from using a software
<zid>
So yea, it's about the entry condition
<zid>
otherwise user programs could do int 8 and pretend a doublefault happened or whatever
junon has joined #osdev
<Kerum>
from what i can tell CPL is bits 0 and 1 of code segment selector
<Kerum>
would that be counting from right to left or vice versa?
<zid>
cpl is the current one
<zid>
in amd64 the value of cs tells you directly on the bottom bits afaik
<zid>
I don't remember for x86
<zid>
Current privilege level (CPL) — The CPL is the privilege level of the currently executing program or task. It
<zid>
is stored in bits 0 and 1 of the CS and SS segment registers.
<zid>
it's ordered, so cs & 3 is your cpl
<Kerum>
thanks for clearing that up
<Kerum>
so DPL is 0
<zid>
DPL of 0 means only the kernel can use it, basically
<zid>
dpl of 3 means anyone can
<Kerum>
then i know what to set it to
<Kerum>
thank you again
<Kerum>
wait
sdfgsdfgDropBear has joined #osdev
<zid>
if I wait much longer I'll start turning blue
<Kerum>
nevermind that wait
unmanbearpig has joined #osdev
nyah has joined #osdev
xenos1984 has joined #osdev
Kerum has quit [Quit: Lost terminal]
dormito has quit [Quit: WeeChat 3.1]
xenos1984 has quit [Ping timeout: 245 seconds]
dennis95 has quit [Quit: Leaving]
dennis95 has joined #osdev
xenos1984 has joined #osdev
Kartikeya has joined #osdev
Kartikeya has quit [Remote host closed the connection]
<travisg>
sounds like a good opportunity to use the power of wiki edit to fix
rorx has joined #osdev
moon-child has quit [Read error: Connection reset by peer]
childlikempress has joined #osdev
jafarlihi has joined #osdev
GeDaMo has quit [Quit: Leaving.]
<Ermine>
I'm not registered yet
dormito has quit [Quit: WeeChat 3.1]
Burgundy has quit [Ping timeout: 252 seconds]
srjek|home has joined #osdev
childlikempress is now known as moon-child
YuutaW has quit [Quit: WeeChat 3.2]
dormito has joined #osdev
<Bitweasil>
*blinks* Anandtech has their A15 analysis out.
<Bitweasil>
Apple definitely likes their caches.
<Bitweasil>
32MB system level cache, 12MB L2 shared between the performance cores, and their L1 is down to single cycle access latency in certain patterns.
<Bitweasil>
And the rest of the chip to back it.
sprock has quit [Ping timeout: 268 seconds]
YuutaW has joined #osdev
elderK has joined #osdev
NeoCron has quit [Quit: Leaving]
<noircode>
If you want to get an overview of modern os design, is it still just the classic texts like the dinosour book?
<Brnocrist>
there are more OS's than books today
<noircode>
really?
<moon-child>
depends on how you qualify 'OS'
<moon-child>
noircode: there is no 'modern os design'. There's the OS design of the 90s, and a few things like containers people have (poorly) packed on top
<noircode>
hmm, for some reason I thought there is a trend around resource usage (containers) and network stacks
<noircode>
so we just get these by side effect or necessity?
<moon-child>
containers are a workaround for language limitations, imo
<noircode>
e.g. you prefer polling drivers becuase of networks, or you skip to userspace entirely
<noircode>
high speed networks*
<noircode>
ok that is a good point, but when I see orchestration stuff, it kinda resembles an os
<moon-child>
have you looked at plan9?
<noircode>
I've read some papers but not closely at it's design
<noircode>
just overview and some networks stuff
<Bitweasil>
Tannenbaum's works and such are probably still a good place to start.
<Bitweasil>
We mostly tack crap on top of that when it fails to scale.
<Bitweasil>
And the whole userspace driver thing isn't really novel either.
<noircode>
ah
<noircode>
I've spent some time on it, but I still don't really have the concept of OS, so I can say "if I wanted to build an OS right now, what would I consider from a design perspective?"
<noircode>
hmm, that's probably because the OS is so general
<geist>
it's a pretty wide open net
<geist>
a lot of it also comes down to what you want to do, which isn't a very satisfactory answer
<Bitweasil>
Well... the first question you should consider is what you want to do with it.
<geist>
but, for example if you wanted to write an embedded system for a microcontroller, or some sort of larger network switch kernel, or a server or a desktop, or a hypervisor, etc
<Bitweasil>
If you want to do some basic time splitting ...
<geist>
you might end up with different solutions
<Bitweasil>
Yeah, that.
<zid>
Timesharing OSes are a thing of the past, old man
<zid>
We just have 256 cores these days, and who needs to run more than 256 programs
<kazinsal>
cooperative multitasking is the future, man
<geist>
lots of the larger ones you can generally cram into the 'build a monolithic mid sized kernel and build drivers and user space on top of it' style thing
<geist>
a-la linux
<noircode>
I see
<zid>
(I'm semi-serious about that, is it even worth not pinning processes to individual cores if you have 512 of them?)
<Bitweasil>
Now that big.LITTLE is becoming more common (even Intel's new stuff has that concept), we're firmly back into the asymmetrical multiprocessing stuff, where it may very well make sense to split cores between OS cores and user task cores.
<geist>
but yes also modern systems have moved towards lots of cores, 64bit
<geist>
which also may change things a bit
<Bitweasil>
It would depend on how many of those tasks are compute bound vs IO bound.
<Bitweasil>
And if you can gate stuff off.
<Bitweasil>
(power-wise)
<geist>
zid: possibly, but then there's also cache and numa and whatnot to consider. so i can think of cases where pinning threads to cores and only running as many cores as you have threads can work against you
<geist>
ie, two threads in the same process not running at the same time probably benefit from running ont he same core more than not
ahalaney has quit [Quit: Leaving]
<noircode>
so the thing is, having all those cores means you want a really nice thread api
<noircode>
right?
<zid>
disregard threads, run more full processes
<zid>
the OS will make it use shared memory automatically
<zid>
(This is personal preference)
<geist>
noircode: having more cores doesn't really change threading much at all
<Bitweasil>
Disregard cores, use blowtorches to turn them back into sand when they misbehave. :D
<geist>
except more chances of at any snapshot in time two threads are running simultaneously
<noircode>
geist: I'm thinking about interupts / context switches
<geist>
and of course race conditions between them are more complex
<geist>
noircode: what do you mean?
<Bitweasil>
If you have enough cores, it starts to make sense to dedicate some of them to interrupt handling, IMO.
<zid>
with more cores you'd do *fewer* context switches
<Bitweasil>
Let their caches remain filled with the ISRs.
<Bitweasil>
As an extreme case, you could have a core do nothing but service ISRs and then HLT.
<Bitweasil>
Its L2 is likely to be very full of ISRs.
<zid>
You only context switch as a painful penalty of trying to run multiple programs and/or with multiple priv. levels on a single core
<noircode>
oh, I didn't know you could do that
<geist>
to be clear context switches also happen between running an idle, but if you consider context switches to be between two threads that are non idle, then yes, more cores mean in general you'll have less contention over a single core
<geist>
all else held equal, and assuming threads are distributed reasonably well across cores
<zid>
geist: hmm what about a hybridy microkernel where you IPI instead of syscall, and have dedicated kernel threads that return the results async, with no context switchign?
<Bitweasil>
Ew.
<geist>
yea, that's pretty eq
<geist>
ew
<Bitweasil>
You could, but I imagine the IPI penalty would be horrid vs a simple syscall.
<geist>
but yes you could do that
<geist>
i think you'd find the performance would be horrendous
<Bitweasil>
There's a vastly wider range of "Well, yes, you could, the hardware will support it" than "This works well."
<zid>
I bet certain applications would benefit from it
<geist>
*especially* on virtual machines, where IPI performance tends to be a few orders of magnitude worse than bare metal
<noircode>
interesting
<zid>
If they don't care about the latency of the syscall or its performance (i/o for example)
<Bitweasil>
Is that true even with the virtual APIC stuff?
<zid>
but they gain back the ability to not have to eat context switches to do those syscalls
<Bitweasil>
I don't know if that can do IPIs without a round trip to the hypervisor.
<geist>
Bitweasil: you start to get into specific details of this or that hypervisor on this or that hardware, but my experience is yes
<Bitweasil>
Doesn't surprise me.
<geist>
in best case you can end up with something not so bad, but in the usual case it's probably at least a round trip to the hypervisor
<Bitweasil>
I really haven't messed with virtual APIC stuff.
<Bitweasil>
ok
<zid>
I was sort of expecting perf to be bad, but with it being async.. you're intentionally disregarding perf sorta
<geist>
we see this somewhat in Zircon since it tends to be a bit more IPI and context switchy than linux or other guests
<geist>
and thus more IPIs
<zid>
So imagine like, prime95 where it wants to run the cpus as hard as it can, and also wants to grab work units from the network and also submit the results back, or such
<kazinsal>
yeah, my experience in the datacenter space is that you're always going to have maximum I/O throughput issues on top of hypervisors simply because there are so many VMEXITs, but for "normal" computing it's fine
<Bitweasil>
kazinsal, if you're doing maximum IO stuff from VMs, don't some storage controllers support passthrough?
<kazinsal>
once you get into the wacky stuff of having a bunch of non-paravirtual NICs and high interrupt rates you start to see deeper perf issues than you would in reality
<Bitweasil>
So you can carve off a "virtual" SSD controller and drop it straight into the guest?
<kazinsal>
Bitweasil: yeah, once you're at that point you ought to be either going into paravirtual adapters or virtualized storage acceleration
<Bitweasil>
Same for the NICs, I know there are some with a ton of PCI devices exposed, so you configure it and hand the PCI device straight off to the VM.
freakazoid12345 has quit [Ping timeout: 246 seconds]
<Bitweasil>
I mean... I use virtio drivers on all my VMs.
<Bitweasil>
Even low utilization stuff.
<Bitweasil>
There are the Windows drivers that Redhat puts out for Windows virtio network/block/display.
<geist>
that does remind me, i wonder if it's possible/inexpensive enough to get a decent virtualizable e1000 nic for a regular PC
<geist>
and more interestingly, actually utilize sharded copies of it on qemu/kvm
<kazinsal>
I think the i350s are e1000-based but have PF/VF functions
<geist>
i think the latter is possible, it just requires some hackery
<kazinsal>
let me check my treasure trove of intel NIC papers
<noircode>
is there any oever head from each process having it's own address space?
<geist>
yah i do wonder exactly how you get them to publish N copies of themselves, map them into the guest, et cetc
<geist>
noircode: yep
<noircode>
hmm
<geist>
but basicaly that ship sailed 40 years ago or so
<geist>
and modern cpus do a pretty good job of keeping the overhead down
<geist>
or at least throw a lot of hardware at dealing with it
<noircode>
ok, makes sense
<geist>
basically for every separate address space you have a separate set of page tables with a different set of virtual -> physical mappings
<kazinsal>
yeah, it's the I350s that are e1000s with SR-IOV and virtual function support
<geist>
and when you switch processes you switch address spaces which means thek ernel switches page tables
<kazinsal>
document ID is 336626-001 for reference
<geist>
and all of that is overhead, but the cpu has large caches for it and mitigates that a lot
<geist>
kazinsal: nice thanks
<Bitweasil>
I... literally can't come up with a single use for a virtual NIC thing around my property. :/
<geist>
not that i need the performance but i do run about 8 VMs on my linux box with just plain qemu/kvm
<Bitweasil>
Yeah, my VMs are either so lightly loaded as to not matter, or just compute nodes.
<geist>
at the moment i just map each of them to a separate tuntap and then bridge it with a dedicated nic
<Bitweasil>
I no longer have *anything* that counts as performance critical.
<geist>
yah agreed. i have also been looking for an excuse to go 10gbe, but the only thing that'd really benefit from it is the VM server to my NAS box, and i could just set up a private cable between the two
<Bitweasil>
Yeah, or one of the 2.5/5Gbit cards, they're a ton cheaper.
<Bitweasil>
Or just go get a coffee and it's done when you get back.
<geist>
ya it hasn't gone over the threshold of things to do yet
<geist>
also the synology nas box wants a particular brand so i have to be a bit careful
<kazinsal>
haven't gotten to the point of RAID10-ing NVMe drives yet
* Bitweasil
wanders out, enjoy the evening!
<geist>
huh wow. $35 2.5GBe card on amazon
<geist>
ah here's a $29 one
<kazinsal>
ooh
<kazinsal>
wonder what the controller on those is
<geist>
ah realtek 8125
<geist>
seems to be all of these from various mfgs
<geist>
realtek strikes again!
<Ermine>
There's a question from xv6 book: they map kernel code and data to 0x80000000. Thus, processes can only use 2Gb of memory. Could raising address of kernel help to increase memory available to process? I think answer is yes, but I'm not sure, because one might have to change process's memory map (move kernel stack or whatever)
<kazinsal>
I wonder how much of the "realtek nics suck" mentality is still accurate
<geist>
Ermine: yes
<kazinsal>
clearly they aren't high end cards but if you just need something chunking out a few gigabits of traffic... are they really that bad?
<geist>
later 32bit kernels (on architectures that support it) tended to do that
<geist>
move the kernel to 0xc000.0000 or even 0xe000.0000
<geist>
64bit generally made that moot
<geist>
kazinsal: oh i think they objectively have less features, but modern computers are far faster so in anythin but server situations i doubt you can tell
<Ermine>
geist: thank you
<geist>
fun fact, when i worked on a robotics thing at work for a bit, we were fiddling with real time networking stuff using EtherCAT
<kazinsal>
oh neat
<geist>
basically needed to be able to squirt out a frame on ethernet on a fixed interval and read then back as quickly as possible
<zid>
fancy serial?
<geist>
found that for the most part the smarter the nic (ie, intel) the harder it was to do that
<geist>
the best nics for that were cheapo realteks with all of the features disabled
<zid>
10000000000000 baud serial :p
<clever>
i think one of the realtek's i checked the drivers on a while back, basically just had 4 regs for the raw dma start addr, 4 regs for size, and 4 regs for status (start, busy)
<geist>
zid: basically. ethercat is kinda neat. uses 100mbit ethernet but basically you build a big loop of nodes where the TX pair goes out, loops through N nodes on the bus, each node clocks in a frame, modifies it in place, and clocks it out a few cycles later
dude12312414 has joined #osdev
<geist>
and the loop comes back to the RX pair on the origin node
<clever>
so you could queue up 4 packets to tx, and dma would just barf them out the cat5 cable
<kazinsal>
what annoys me is I can't seem to find a programming guide for the 8125... seems to be some example drivers on realtek's site but no nice chunky PDF
<geist>
basically you toss an ethernet frame out with a bunch of slots reserved for various nodes, and the nodes modify them in place
<geist>
you start receiving the response packet before you've even finished sending it
<clever>
oh, now that is crazy
<geist>
basically each node adds a few clock cycles of delay
<clever>
i dont think i could reply to a packet that quickly on any hw i own
<clever>
not without an fpga
<geist>
cool thing is the head unit doesn't have to be fancy, just a plain nic on a PC will work
<geist>
the nodes themxelves are using an asic (or FPGA) that modifies the packet as it clocks through, including recomputing the CRC
<clever>
ahh
<clever>
and you would hack it into a bit of a token ring?
<clever>
so the tx from the pc, goes thru each node, and right back to rx?
<geist>
right
<geist>
each node adds a few cycles of skew to it
<clever>
like a non-store&forward switch
<geist>
the ethercat frame has a standard ethernet header + some header that says 'in the rest of the frame at offset X i want report Y from node Z' with a few of those
<clever>
where you just check the 6 byte dest addr, and immediately begin forwarding, with 6 bytes of latency
<geist>
no, it's a distinct ethernet type
<geist>
it's not that simple. it actually has a frame and whatnot
<clever>
but similar in terms of the "forwarding" delay
<geist>
right
<clever>
but it will mutate as it forwards
<geist>
right
<kazinsal>
great, realtek's 8125 sample driver is GPLed. time to scrub this from my brain
<geist>
kazinsal: :(
<geist>
bummer, realtek is usually okay about releasing specs
<zid>
that actually.. sounds a lot like usb
<zid>
Bastard child of ethernet and usb
<kazinsal>
yeah, I'm trying to find their documentation portal or something that I can hopefully find a pdf for this thing on
<geist>
zid: sort of, except the chaining part, but the idea that you toss out a header and then leave a gap for the device to insert its bits, yeah
<geist>
anyway, it's a lot faster than say CAN bus or whatnot
<geist>
but downside is ethercat is proprietary
<geist>
though you can pay for it
<zid>
It has that weird 'I know what I am expecting back' aspect of USB
<zid>
telling the other side what the response length will be always struck me as odd
<geist>
well, ethercat is standardized, but i think there's some stuff you have to license
<geist>
zid: yeah it's very very much speak-when-spoken-to
<zid>
"Hello my name is zid, you're going to tell me your name too in 14 characters, each character is an ascii character" :p
<geist>
at least classic USB. USB 3 is kinda a mind screw of a point to point much more sophisiticated thing that still pretends its the old thing
<zid>
yea I've never dealt with fireusb wire 3.0 lightningbolt over pci-e for workstations 3.11
<zid>
I bet it's.. trying very hard
<geist>
if you get a chance, i highly recommend getting a usb bus analyzer. it's very educational
<clever>
zid: lol
<geist>
i bet you can get old ones cheap on ebay or whatnot not
<zid>
I know the usb 1 spec enoug for hid
<zid>
which is what I use it for
<clever>
geist: if you dont care about the low-level encoding, usbmon is still great
<zid>
I had to deal with it on the software side on windows, then learned the line encoding for it all later
<clever>
but usbmon requires well-formed packets
<geist>
did you see ben eaters version of it? he did some fun manual probing and decoding with his scope
<clever>
and ive had problems where my bugs where creating malformed packets, so the kernel/usb-controller just dropped it
<zid>
yea that's where I learned the line level version :D
<geist>
though it helps that he has a nice agilent scope that can actually do some framing
<zid>
but I knew what would be in all the packets
<clever>
geist: yeah, and i kept screaming to use usb mon, and to stop decoding the bits by hand, lol
<geist>
yah same. it was fun to watch, but nothing i hadn't seen before
<clever>
show how to decode them once, but then switch to proper tools
<zid>
I liked his ethernet one, I didn't know about the.. PAL colourbust it does etc
<clever>
dont cripple yourself by decoding by hand forever
<zid>
HID on windows is weird btw, I *still* don't undertand how joy.cpl gets the device names
<clever>
zid: my motherboard identifies itself as an HID device, so it can run on windows without drivers
<zid>
your motherboard runs on windows?
<clever>
as-in, one of the host mode ports, turns into a device mode port (double-ended cable), and claims to be an HID device
<clever>
with the right software, you can then query the cpu temp, cpu amps, and fan speed, over that usb cable
<zid>
ah right
<clever>
from a second machine
<zid>
there's a header for that on most boards
<zid>
der8auer (sp) likes to bust out his tool for it
<clever>
for my system, its just a regular usb-a host port on the back, with a switch to put it into gadget mode
<zid>
when hes' doing extreme OC it's easier to poke all those values via the header than msi afterburner or whatever
<clever>
and you use a spec-bending a to a cable, that connects 2 port ports
<zid>
yea doing it over HID makes sense tbh
<clever>
ive checked it with usbmon, and its just sending .ini files over
<zid>
I'm sure there's a usage page for thermometers and stuff
<clever>
but you need to write an HID packet to the MB, to cycle to the next page
<clever>
and .ini records are cut off at the page border
<geist>
kazinsal: heh that's a bad sign when you download the freebsd driver for the 8125 from realteks site
<geist>
and it turns out to be a shared implementation with the 8139
<geist>
anyway 8169 is a fairly capable gigabit one, so makes sense it's probably just extended to 2.5
<kazinsal>
I'm glad they cleaned that driver up, at one point iirc the source file was a meg long and was 80% bitbanging firmware word by word into the NIC
<clever>
kazinsal: wut? lol
<geist>
iirc the 8169 is not too bad, just a TX and RX descriptor queue that does what it does
<geist>
not fancy, but gets it done
<kazinsal>
yeah once upon a time most of that driver was a giant phy config function that was half a meg of write_phy calls
<clever>
kazinsal: that reminds me, i still need to figure out what usb PHY is on the rpi
<clever>
ive found ways to configure it, but no details on what i'm actually doing
<clever>
if mis-configured, it can silently corrupt every ssh packet from the usb nic
<clever>
and the usb nic must be doing checksum accel on the nic side, and then assuming the usb link is lossless
<GreaseMonkey>
huh, where is this classic rant
<geist>
GreaseMonkey: seems to be gone now
<geist>
basically was a rant about how realtek has set the bar for new low and how shitty it was, etc