<bslsk05>
www.swift.org: Swift.org - Platform Support
<radens>
Is there like some respected tiny jvm project or something? Or is the jvm too big?
<radens>
It's like none of these languages really fit the need but as I write more userland code I want to write less C while taking the path of least resistance.
<Mutabah>
Port rust? :D
<klange>
make your own language
<radens>
honestly sounds easier than anything else I've mentioned :|
<moon-child>
radens: have you looked at d or common lisp? Neither requires very much platform support
<radens>
klange: thought crossed my mind
<radens>
moon-child: I don't really know much about either, I should look
<klange>
I say having made next to nothing in Kuroko...
<pounce>
moon-child: can you compile clisp
CaCode_ has joined #osdev
<moon-child>
pounce: clisp is written in c, and most c implementations are compilers, so yes. Clisp isn't a particularly good cl implementation though
CaCode has quit [Ping timeout: 260 seconds]
dude12312414 has joined #osdev
<junon>
Difference between LPDDR3/4/5 and DDR3/4/5?
<moon-child>
L = Laptop, I think
<junon>
ah yes
<moon-child>
low-power, apparently
<junon>
lp = low power
<junon>
thanks moon-child :)
_whitelogger has joined #osdev
xing_song1 has joined #osdev
mimmy has joined #osdev
mimmy has quit [Ping timeout: 256 seconds]
CaCode_ has quit [Ping timeout: 256 seconds]
nyah has quit [Ping timeout: 240 seconds]
<geist>
radens: i've been told that rust has about the same requirements as C
<geist>
in that it largely sits on top of standard libcs
<junon>
> go runtime, syscalls
<junon>
yes, go implements its own syscalls
<junon>
also really complex things such as coroutines are implemented at the language level
<junon>
> swift, off macos
<junon>
in theory.
<geist>
oh absolutely. the Go port for fuchsia is an experience
<geist>
especially since fuchsia has nothing really to do with posix at the syscall level
<radens>
an experience?
<geist>
AN EXPERIENCE
<junon>
geist: people are porting Zircon to Go?
<junon>
wtf
<junon>
why
<geist>
what?
<junon>
OH
<pounce>
geist: doesn't rob pike work at google
<pounce>
why didn't ya make him do it
<junon>
people are porting Go to Fuchsia
<radens>
Damn okay, crossing Go off the list from the caps alone
<geist>
yeah
<geist>
no i just mean that go expects to talk directly to the syscall layer, so we had to build its own syscall glue
<junon>
sorry, whiskey-brain
<junon>
right, yeah
<junon>
but IIRC posix doesn't specify syscalls, just C functions, right?
<geist>
i dont actually know how much work it was to do the appropriate emulations of concepts like stdio/etc in its runtime
<brynet>
OpenBSD switched Go to using libc rather than it's weird poorly maintained syscall layer, IIRC the macOS and Solaris ports work the same.
<geist>
rioght, but it implies a certain model: file descriptors, stdin/stdout/etc, signals, fork, etc
<junon>
meh
<junon>
antiquated.
<radens>
Go must call into ntdll on windows too, right?
<geist>
unknown.
<junon>
errrrrrr good question
<geist>
question is how much does ntdll model after similar things
<junon>
It must, because windows syscalls are all over the place.
<geist>
file descriptors, stdout/etc
<junon>
I knew the answer to this at one point
<junon>
going down the language design rabbit hole
<kazinsal>
not sure where my copy of windows internals volume 1 is
<junon>
Alice only went to level 1, language design is at, like, level 15
<geist>
i think the answer is NT is not posix per se, but in a similar family of kernels that provide similar things (and more)
<geist>
win32 is not completely foreign to posix universe
<geist>
has roughly wheels in the same place, engine attached to the wheel in similar ways
<geist>
though one may be a 2 stroke and another is a wankel
<junon>
Interesting, Go makes the distinction between syscalls on the 386 for windows and x86
<junon>
I wonder how they relate.
Oli has quit [Quit: leaving]
<geist>
hmm, maybe that's int vs sysenter?
<geist>
or x86 is x86-64 in their naming convention?
<bslsk05>
j00ru.vexillium.org: Microsoft Windows System Call Table (XP/2003/Vista/2008/7/2012/8/10)
<junon>
click "show all" and watch the tab freeze for a few seconds lmfao
<geist>
yah zircon also avoids the numbering thing by presenting the syscall interface as a ELF dylib
<geist>
that you *must* link with
<geist>
(that's also a problem for Go, since it doesn't do ELF)
<junon>
Go doesn't do elf?
<geist>
it's my understanding that all go binaries are statically linked and thus dont do any dynamic linking aside form whatever loaded the binary in the first place
<junon>
Oh right
<geist>
it might do ELF from a debug symbol point of view, but not a dyloader
mimmy has joined #osdev
<geist>
some chance i'm full of crap though, so dont quote me on it
<junon>
geist you're full of crap
<geist>
i've not looked into go that much but i had heard second hand from folsk porting it
<junon>
but yeah, I think you're right
<junon>
I'm somewhere on the fence of "use ELF for my own executables" and "ELF is so dated and bloated as it is, make something simpler".
<junon>
ELF seems very system-v oriented
<geist>
go with the former. unless you have a real desire to do a crapton of tool work, i would probably just stick with it
<geist>
it's flexible enough that you can generally bash it into whatever shape you need
<radens>
I think the go people are high. Windows, OpenBSD, Zircon all have the same issues and they are fighting to make it look like the world is all plan-9 or systemV
<junon>
tool work is fun though
<klange>
The good thing about ELF is that there are myriad tools that understand it.
mimmy has quit [Ping timeout: 260 seconds]
<junon>
but yeah
<geist>
and it is already ported to pretty much all the arches
<geist>
relocations and whatnot you probably dont want to have to re-invent
<junon>
radens: I agree. It comes down to the pretty stupidly common tradeoff of "status quo" and "what might be better, but more time-consuming"
<radens>
junon: what do you think the issue with Elf is? Seems tons better than PE.
<klange>
While I opted to DIY all my code, I also opted to implement existing things - makes for good learnings.
<geist>
well, i mean it does beat a sharp stick to the eye (PE)
<junon>
PE is a dumpster fire, a PNG is a better format
<junon>
ELF has implementation defined flags in it, which is the first thing that comes to mind.
<junon>
fourcc-based formats are great IMO but ELF isn't generic enough for my personal liking.
<junon>
But it's not enough to really say "it's not worth it"
<radens>
junon: if it didn't have implementation defined flags then every OS vendor would make one anyway :P
<junon>
Only those opposed to open standards. Yes.
<junon>
(which, of course, is almost all of them)
<raggi>
geist: go knows how to parse Linux vdso, and had an elf lib in the compiler, there's been some dynamic linking for Linux for a long time now, we just didn't port it
<junon>
"we" are you on the Go team, per chance? (just curious)
<geist>
ah, was it present at the time we were starting the port (2016)?
<raggi>
The challenges we had with our fuchsia port were mostly it's age and lack of investment to keep it up. We chaned a lot about or strategy since we started our port
<radens>
The one beef with elf tooling I have is that it should be easier to make a flat binary which uses pc relative addressing everywhere.
<raggi>
E.g. the go port started without any dep on libfdio, which pretty much means linking in other libs had a whole breed of new headaches
<raggi>
(which in some circumstances is a good thing, in others not, ideally it would dep fdio w/cgo and not without cgo, but unless we have an immediate use case (we don't) it'd be more work
<raggi>
junon: I work on fuchsia and maintained our go port for several years
<junon>
ah okay
<geist>
radens: some of that is ABI issues
<geist>
ie, standard vtables have a hard coded address
<geist>
or for that matter any jump table the compiler generates (usually)
<geist>
we actually switched fuchsia to a relative vtable scheme lately, but that was an ABI breaker
<raggi>
As for the commentary about shoving everything through a posix abstraction, I think that's slightly missed - their abstraction is posixish, but not even really posix. It's a relatively "common denominator fd-ish" abstraction and it works ok. Anyone who tries to make a single abstraction over the problem space runs into similar challenges, theirs isn't significantly better or worse than the status quo
<radens>
Hadn't thought of the vtables good point
<junon>
geist: what do you mean by vtable scheme?
<geist>
raggi: yah that i was unsure about. how much the internals of Go relied on a C/posixy style of file descriptors and whatnot under the hood
freakazoid343 has joined #osdev
<raggi>
Not entirely, you could use handles
<raggi>
But to do so you have to write more runtime code
<junon>
Oh zircon is written in C++
<raggi>
We forced ourselves down an FD path to be able to use most of the Unix code paths, which was less initial effort
<raggi>
If we'd kept using go, I'd eventually have rewritten it to use handles and ports more directly, I made a plan to in 2019, but we never prioritized it
<radens>
raggi: kept using? Why didn't you keep using it?
<raggi>
After deliberation about the tradeoffs we decided that the runtime overhead was higher than we want for most production software, and with c++ and rust as our alternatives it doesn't have a significant amount role to play for us in nonproduction code
<raggi>
Though we still use it in some areas. You could also reduce the cost of the runtime, but doing so is a relatively large initial and ongoing cost, for example avoiding fmt and reflect, maintaining a runtime fork, etc
<radens>
A fair analysis. Still from the outside it seems like a bit of organizational disfunction to make supporting the Google programming language on the google OS so hard. (Not like I haven't participated in organizations with similar dysfunction)
<raggi>
Putting this in a much simpler way: a go hello world weighs a similar binary size to a dozen rust/c++ programs, out of the box
<radens>
nice
<raggi>
That seems to be based on an assumption that a massive company has and/or must have a single set of goals with an infinite power to make them all exactly and entirely congruent
<junon>
hehe
<radens>
I am surprised they aren't a little better aligned
<junon>
Uber tried to reduce the four official languages (Go/Java/Python/Node.js) down to two (Java and Go). Didn't work.
<raggi>
Does every OS target every use case?
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
<raggi>
A Go that was significantly better suited to lower level development would have quite different ergonomics in a lot of areas, as you'd lose most of the ergonomics in most of the stdlib that makes it so good for cloudy systems glue stuff
<raggi>
(e.g. if you ban the fmt package, you lose over 50% of the stdlib)
<raggi>
i guess teh final thing worth noting is that while we aren't using it for new stuff, it's still the langauge that our current network stack and package filesystem are written in, and in those roles it's functioning just great for the use cases
<pounce>
radens: idea: crystal lang
<raggi>
i like the idea of crystal, as i did a lto of ruby a long time ago, but i've not looked deeply at it's implementation
<pounce>
it supports quite a few platforms (like rust) might be able to port?
mimmy has joined #osdev
<raggi>
it likely has a large runtime
<radens>
pounce: interesting thought I'll look it up
<raggi>
but i'm guessing about that
<junon>
the runtime cost is always a concern.
<junon>
usually neo-languages like crystal, go, zig et al have huge runtimes
<junon>
or unstable runtimes, for example.
<junon>
for example zig*
<radens>
I'm okay with a larger runtime if it's easier to port
<pounce>
radens: said GC'd
<pounce>
so im not sure why you would want GC but no runtime
<raggi>
it's actually relatively easy to rip go's runtime into pieces and replace it, same with zig, but it does mean forking, and the api isn't stable, so the cost of ownership fo the fork is perpetually somewhat high
<junon>
yes but then you cut out embedded environment, which might be acceptable to you.
<junon>
raggi: precisely.
<radens>
Zig is an interesting idea -- not gc'd still has UAF's but supposedly in the space between go and rust based on what I read?
<raggi>
updating our runtime fork for the large compiler changes when they brouhgt in their optimizer and rewrote their reactors was quite painful
<junon>
Zig is between C and Go IMO
<raggi>
yeah, zig is quite nice in principle, there's a lot to like about the toolchain behaviors. i'm really not keen on the stdlib though, it feels chaotic compared with the core language
<radens>
chaotic?
<junon>
well... maybe between Go and Rust. It's a 2D plane tbh.
<raggi>
completion and organization are pretty arbitrary
<raggi>
a big lack of consistent naming, etc
<junon>
Zig has a bad a STD implementation. The maintainer (andrew) has agreed on that point in the past. I've been pretty critical of it historically. But the language itself is solid.
<junon>
And he's more than capable of writing a compiler.
<raggi>
yeah, if i was younger i might be tempted to write a stdlib for it
<junon>
I wouldn't place weight on it right now but it's a strong contender for the future IMO.
<junon>
yeah.
mimmy has quit [Ping timeout: 268 seconds]
<junon>
If Zig were more mature I'd prefer it over C.
<junon>
And I love C.
<raggi>
each time i've gone to use it in that place the stdlib drove me away sadly, and i ended up using rust or go, depending on the case
<junon>
yeah, same.
<junon>
There was a one-liner DOS exploit for the utf-8 module I discovered at one point. The std needs a complete rewrite IMO. I think it'll happen though.
<raggi>
maybe i should write a bootloader in zig
<junon>
raggi: Zig already has full UEFI support as a std module.
<junon>
It's quite impressive tbh.
<raggi>
is it generated from the spec?
<radens>
You can still UAF in zig, right? No GC?
<radens>
raggi: generated?
<junon>
raggi: no lol
<junon>
not even close
<raggi>
that's a pretty large api surface if they did everything :o
<raggi>
from what i remember, that'd be larger than most of the rest of the stdlib
<junon>
utf-8, not unicode
<junon>
two different things.
<junon>
utf-8 encoding/decoding is rather simple.
<junon>
full unicode support is a fucking jungle of nonsense.
<junon>
radens: uhhhhh maybe? I can't remember.
<raggi>
radens: yes, but it's less common
<junon>
But no, zig is not GC.
<junon>
I think raggi is right, it doesn't protect against UAF but it does reduce the annoying bits about it. Plus, UAF isn't a PITA unless you don't have access to tools like valgrind.
<junon>
wheras Rust outright prevents it and also prevents you from doing things that are safe and more performant
<bslsk05>
github.com: Generate checks for all forms of UB in Debug and ReleaseSafe modes · Issue #2301 · ziglang/zig · GitHub
<junon>
Unless you use the socially unacceptable `unsafe` everywhere.
<radens>
junon: I'm more concerned about a security perspective than tracking down uafs.
<junon>
Define "security". What's your threat model?
<junon>
:D
<raggi>
when we're tlaking about langauges we're talking about the "I'm stupid" threat :)
<junon>
well, that exists in any language.
<raggi>
right, but it's much harder to fall off a bike with training wheels than without
<junon>
You can write coq theorums that are wrong
<junon>
and still prove that the wrong theorums are represented accurately in C.
<junon>
from a "CI" perspective, everything would be green, but your anti-nuke turrets you wrote firmware for will still fire missiles at a mcdonalds down the road.
<junon>
The road to formalized verification is rocky and full of false promises. "memory safety" is one of them, and I see Rust mis-represented all the time on online spaces.
<radens>
I mean, it's easy to say "don't be stupid" and then someone turns finds a UAF in a JS engine escape, and then finds a UAF in win32k and just hijacked your kernel because you had the gall to click a link
<junon>
Zig just chooses to exists somewhere in between C and Rust in terms of safety.
<junon>
radens: you joke, but someone I worked with 100% confirmed legitimately wrote a Node.js controller for some Russian tanks.
<raggi>
when i eventually give up my last mac devices, zig may end up finding it's place as my mac cross compiler, as they solved that problem
<junon>
It was an experimental project but... we all know how experiments tend to find their way into production.
<radens>
junon: idk I think "no UAFs" should be the bar going forward, and zig doesn't quite meet that bar.
<junon>
UAF is such an easy thing to debug though...
<junon>
and an easy thing to guard against
<raggi>
only if it crashes
<radens>
^^
<junon>
memory leaks are much more interesting since they can exist even in formally verified programs.
<radens>
Or even, only if you remember to exercise that code path
<junon>
UAF is such a small subset of memory issues.
<radens>
junon: let me pull up some MS research which says they're actually a huge amount of MSRCs
<junon>
Fine, do that.
<junon>
My point is, they're not hard to check for.
<junon>
Or fix.
<junon>
Memory leaks are not. It's not easy to discern between "it's supposed to take up this much memory" and "this is a logic error"
<moon-child>
yeah, 'memory leak' is not really well-defined
<junon>
because there is no way to automatically detect logic errors.
<bslsk05>
reviews.llvm.org: ⚙ D99861 [Clang] Record tokens in attribute arguments for user-defined C++/C2x attributes
<bslsk05>
reviews.llvm.org: ⚙ D99877 [Clang] Allow processing of attributes on statements by plugins
<moon-child>
anyone know if there's a protocol for asking the cpu what is in cache? (on any arch)
<raggi>
go
<raggi>
go's compiler is pretty fast, you could use go as an IR :-P
<radens>
moon-child: none that I know of which isn't a spectre side channel attack :P
<Mutabah>
moon-child: Try to access it and time how long it takes?
<moon-child>
radens: :D
<moon-child>
Mutabah: hoping for something more direct than that
<moon-child>
more like 'tell me all of the things that are in cache' than 'tell me whether this one thing is in cache'
<Mutabah>
Why do you want that information?
mimmy has joined #osdev
<junon>
debugging.
<radens>
I had a colleague who wanted to reverse engineer a model of the intel cache for spectre security research because he couldn't get that
<junon>
would be insanely useful.
<moon-child>
Mutabah: gc
<moon-child>
relocate objects which are accessed together to be close to each other
<radens>
You can get a high level picture with perf counters
<junon>
that too
* junon
heads to bed
<junon>
night everyone
srjek|home has quit [Ping timeout: 250 seconds]
<moon-child>
night!
mimmy has quit [Ping timeout: 260 seconds]
YuutaW has quit [Read error: Connection reset by peer]
_xor has quit [Read error: Connection reset by peer]
_xor has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
mimmy has joined #osdev
mimmy has quit [Ping timeout: 256 seconds]
CaCode has joined #osdev
sdfgsdfg has joined #osdev
Burgundy has joined #osdev
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
mimmy has joined #osdev
<geist>
ugh there are like 10000 e1000 pci ids
<geist>
guess it still makes sense to search it via ids though, since just matching anything ethernet subclass against 8086 is probably not the right strategy
mimmy has quit [Ping timeout: 256 seconds]
<zid>
yea just add them as they come I guess, or steal the list from the linux kernel
<kazinsal>
yeah, and not all of the e1000 models support various things like MSI or EEPROM
<zid>
100E and 100F are the ones qemu and bochs and stuff It hink
<zid>
use*
JerryXiao has quit [Quit: Bye]
<geist>
yah
JerryXiao has joined #osdev
mimmy has joined #osdev
mimmy has quit [Ping timeout: 240 seconds]
elderK has quit [Quit: Connection closed for inactivity]
mimmy has joined #osdev
xing_song1 has quit [Read error: Connection reset by peer]
mimmy has quit [Ping timeout: 260 seconds]
bauen1 has quit [Ping timeout: 265 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
mimmy has joined #osdev
mimmy has quit [Ping timeout: 256 seconds]
heat_ has quit [Ping timeout: 260 seconds]
ElectronApps has joined #osdev
xing_song1 has joined #osdev
the_lanetly_052_ has joined #osdev
Burgundy has quit [Ping timeout: 252 seconds]
mimmy has joined #osdev
mimmy has quit [Ping timeout: 268 seconds]
bauen1 has joined #osdev
xenos1984 has quit [Quit: Leaving.]
fwg has joined #osdev
jjuran has quit [Ping timeout: 268 seconds]
xenos1984 has joined #osdev
jjuran has joined #osdev
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
xenos1984 has quit [Quit: Leaving.]
xing_song1 has quit [Read error: Connection reset by peer]
gog has joined #osdev
dennis95 has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
bauen1 has joined #osdev
sortie has quit [Remote host closed the connection]
sortie has joined #osdev
fwg has quit [Quit: .oO( zzZzZzz ...]
<geist>
Gotta say this intel Ethernet is pretty straightforward
zaquest has quit [Remote host closed the connection]
<geist>
At least the older one qemu is emulating by default
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
<geist>
82540 it seems
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
pretty_dumm_guy has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
zaquest has joined #osdev
<klange>
The whole line is backwards compatible, and there was even a single driver in Linux for a long time (but it eventually got broken up because supporting the legacy approaches on the newer hardware was becoming unmaintainable)
<klange>
My T410 has one of the PCIe ones, and my drivers work with it, though I was doing some initialization wrong at some point and it was only doing 10mbit for a while :D
heat_ has joined #osdev
heat_ has quit [Remote host closed the connection]
GeDaMo has joined #osdev
elastic_1 has joined #osdev
elastic_dog has quit [Quit: elastic_dog]
xenos1984 has joined #osdev
CaCode has quit [Quit: Leaving]
xenos1984 has quit [Quit: Leaving.]
Burgundy has joined #osdev
dormito has joined #osdev
bauen1 has quit [Remote host closed the connection]
[itchyjunk] has joined #osdev
DaftMouse has joined #osdev
freakazoid343 has quit [Ping timeout: 250 seconds]
bauen1 has joined #osdev
vdamewood has joined #osdev
Oli has joined #osdev
mimmy has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
xenos1984 has joined #osdev
dormito has quit [Ping timeout: 252 seconds]
bauen1 has quit [Ping timeout: 240 seconds]
DaftMouse has quit [Remote host closed the connection]
dormito has joined #osdev
bauen1 has joined #osdev
mimmy has quit [Ping timeout: 240 seconds]
mimmy has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
[itchyjunk] has quit [Read error: Connection reset by peer]
srjek|home has joined #osdev
ElectronApps has quit [Remote host closed the connection]
mimmy_ has joined #osdev
mimmy has quit [Ping timeout: 250 seconds]
bauen1 has joined #osdev
bauen1 has quit [Ping timeout: 268 seconds]
bauen1 has joined #osdev
bauen1 has quit [Ping timeout: 268 seconds]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mimmy_ has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
mimmy_ has joined #osdev
freakazoid333 has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.3]
vdamewood has joined #osdev
mimmy_ has quit [Ping timeout: 252 seconds]
x88x88x has quit [Read error: Connection reset by peer]
freakazoid333 has quit [Ping timeout: 250 seconds]
freakazoid343 has joined #osdev
freakazoid343 has quit [Remote host closed the connection]
mimmy_ has joined #osdev
mimmy_ has quit [Client Quit]
SpikeHeron has joined #osdev
mahmutov has joined #osdev
xenos1984 has quit [Quit: Leaving.]
xenos1984 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 250 seconds]
<geist>
yah the e1000e seems to be where they snapped and decided to make a newer driver
<geist>
i think that basically lines up with the i210
<geist>
but i've done a quick comparison of the i210 docs with older stuff and it's definitely still the same basic design
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<zid>
That's why I just read the qemu source for what stuff was actually part of a 'normal' e1000
<zid>
and what stuff was i210 and i57 or whatever the hell the older stuff was
x88x88x has joined #osdev
<geist>
yah even the 82540 already has some legacy, it talks about not using the receive timeout thing and use some newer variant of it
<geist>
like you can use it but it recommends using the newer thing
<geist>
looks like i210 is where it picks up multiple rings for rx and tx and whatnot. that might be a pretty good spot for a new driver since it starts to really modify the flow of the code
<geist>
ie, e1000e
<zid>
Thankfully it's going to be a long ass time before I can see getting a usermode that cares about vlans and other stuff so I literally just shoved a page into each buffer, set it to super promiscuous settings and disabled all the 'extras'
<zid>
and gg
<zid>
interrupt code is like 3 lines to move the head/tail
ThinkT510 has quit [Quit: WeeChat 3.3]
<geist>
yep
<geist>
i knew it was a ring buffer thing, but this particular design is nice and simple. i've seen some where you have a queue head that points to a chain of things, etc etc. this flat ring seems much more straightforward
<geist>
from what i can tell this seems to be the general design of modern stuff. probably simple flat ring is better for efficient descriptor transfer over DMA. there's a bunch of talk in the manual about precisely how the card prefetches descriptors and when it burst dmas results back, etc
<geist>
guess the only teensy bummer is you need contiguous memory for the ring, or you keep the number of entries to a single page. but so it goes.
<geist>
the logic of dealing with the ring descriptors on a cache incoherent system may require a bit of thought, but i think it's probably straightforward
<geist>
i think it says you can write null ring descriptors that the device will skip, so worst case you could arrange for all of the descriptors for a single packet to never share a cache line with any other ones
ThinkT510 has joined #osdev
<geist>
so on rx when it writes back you can invalidate and go. or probably just map the ring as uncached
dude12312414 has joined #osdev
srjek_ has quit [Ping timeout: 260 seconds]
kernelspace has joined #osdev
<kernelspace>
hi, trying to figure out, about the arm psci "cpu_on"
<kernelspace>
in linux, i am finding ; [ 0.104763] psci: __psci_cpu_on() fn 95c1ba60
<kernelspace>
not clear where to find docs about the 95c1ba60 address
<kernelspace>
not able to find in any datasheet from where that address comes from
<j`ey>
kernelspace: CPU_ON, you give the CPU an address
<kernelspace>
it's like a psci function-call address
<j`ey>
kernelspace: did you add that print?
<j`ey>
no
<j`ey>
PSCI uses hvc or smc
<kernelspace>
now i found #define KVM_PSCI_FN_BASE 0x95c1ba5e
<kernelspace>
j`ey: ok, seems smc in my case
<kernelspace>
yes i added that printk
<kernelspace>
what i don't understand is what is that "0x95c1ba5e", is it really an address ?
<j`ey>
95c1ba5e says PCSI base
<j`ey>
if you squint
<geist>
unclear, most likely it's whatever kernel you happen to be trying to debug I assume?
<j`ey>
9 =~ P
<j`ey>
5 =~ S
<geist>
oh haha, yeah
<j`ey>
kernelspace: I think you can ignore that. for psci you move args into registers and call smc
<kernelspace>
ah. ok. i thought base means a memory address that get called
<geist>
there are actual docs on PSCI, i recommend looking them up on arms site
<j`ey>
^
<kernelspace>
ok will check better, thanks
<geist>
it's pretty simple, basically looks like a syscall from the kernel, and the calling convention is pretty simple
<j`ey>
basically like the normal convention
<geist>
in the case of CPU_ON you basically specify which cpu (using a MPIDR like id) and the start address and you can pass an arg to it that shows up in x0
<geist>
j`ey: sadly there was some fiddling of that post 0.2
<geist>
and seems a lot of implementations are still 0.2
<geist>
or whatever the pre-1.0 version is
<geist>
prevous versions were unclear/inconsistent about what is saved/trashed. 1.0 tightened that up
<kernelspace>
thanks, looking into psci/smc docs
<j`ey>
kernelspace: btw what did you print, was it entry_point ?