this post was submitted on 29 Dec 2023
14 points (100.0% liked)
programming
174 readers
1 users here now
-
Post about programming, interesting repos, learning to program, etc. Let's try to keep free software posts in the c/libre comm unless the post is about the programming/is to the repo.
-
Do not doxx yourself by posting a repo that is yours and in any way leads to your personally identifying information. Use reports if necessary to alert mods to a potential doxxing.
-
Be kind, keep struggle sessions focused on the topic of programming.
founded 11 months ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It's pretty uncommon for low-level system APIs to use callbacks in that way. Think about it: every time the kernel wants to notify the user of an event, it would have to call a function in userspace... but there are a few problems with that. For starters: which thread is it calling from? The user process isn't going to have stack mappings and whatnot set up for an arbitrary kernel thread. And if we set that aside for the time being, in order to actually run the callback, you'd have to make a context switch from kernel to user mode as well, for each event.
The kind of API shown in the example is much more common: userspace allocatesa buffer, makes a syscall to request the kernel to copy queued events into the buffer until it fills up or no more events are pending, and then iterate over them again in userspace. A higher-level userspace library might hide this away behind a simplified interface with a callback function, but somewhere down the abstraction hierarchy it's almost certainly going to end up looking something like this.
Ah, good point. Yeah, in my mind, there was a thin wrapper library to allocate that buffer and such. Guess, we can't have that for the actual exposed interface.
I was also thinking, having to pass the size of the buffer and the buffer pointer separately, is just another C-ism, but that does make sense here then, too, because it's not implicitly relying on the memory layout of some List/Vec/whatever type.
Similarly,
ETWGetEventscan only return a number of events, because it can't return a List/Vec/whatever.Interesting perspective. And kind of weird to now be on-board with this API design, while also thinking I'm not touching that without a wrapper.
Maybe in a few decades, the Rust ABI will have stabilized and become ubiquitous enough, that we can have at least some of these amenities. But chances are, Rust will look quite antique by then, too, and we're back to writing wrappers anyways. ๐