161–170 of 234 posts
> Linux-compatible ABI There's no specification of that ABI, much less a compliance test suite. How complete is this compatibility?
While developing the lx brand on illumos/SmartOS, ltp was helpful. It may not be complete, but it is a pretty good start. https://linux-test-project.readthedocs.io/en/latest/
I think this looks incredible. Like how does one create a compatible abi _for all of linux_??? Wow! > utilize the more productive Rust programming language Nitpick: it’s 2024 and these ‘more productive’ comparisons are silly, completely unscientific, And a bit of a red flag for your project: The most productive language for a developer is the one they understand what is happening one layer below the level of abstract…
> Like how does one create a compatible abi _for all of linux_??? You look at Linux's syscall table[0], read through the documentation to figure out the arguments, data types, flags, return values, etc., and then implement that in your kernel. The Linux ABI is just its "library" interface to userspace. It's probably not that difficult; writing the rest of the kernel itself is more challenging, and, frankly, more inte…
As well as some subset of the files expected in /dev, /proc, /sys, and similar, which are also part of the userspace ABI. And the startup mechanisms for processes, and the layout of AUXV...
It's absolutely doable, but the interface is wider than just the syscall layer.
Earlier quoted context omitted.
Otherwise is a decent language but what makes it difficult is the borrow semantics and lifetimes. Lifetimes are more complicated to get your head around. But then there's this Arc, Ref, Pinning and what not - how deep is that rabbit hole?
I always feel Arc is the admission that the borrow checker with different/overlapping lifetimes is too difficult, despite what many Rust developers - who liberally use Arc - claim.
Earlier quoted context omitted.
It's not that the borrow checker is too difficult, it's that it's too limiting. The _static_ borrow checker can only check what is _statically_ verifiable, which is but a subset of valid programs. There are few things more frustrating than doing something you know is correct, but that you cannot express in your language.
For kernels (and I suspect database engines might be added to the list, since they seem to have similar requirements to be both scalable and deal with massive amounts of shared state, but I'm not overly familiar with them) is where it gets particularly difficult. Several kernels for example use type-stable memory, memory that is guaranteed to only hold objects of a particular type, though perhaps only providing that…
Decades ago Linus Torvalds was asked in an interview if he feared Linux to be replaced by something new. His answer was that some day someone young and hungry would come along, but unless they liked writing device drivers Linux would be safe. This is all paraphrased from my memory, so take it with a grain of salt. I think the gist of it is still valid: Projects like Asterinas are interesting and have a place, but the…
> docker run -it --privileged --network=host --device=/dev/kvm -v $(pwd)/asterinas:/root/asterinas asterinas/asterinas:0.9.3 Is that the new generation of curl | bashism in action?
Earlier quoted context omitted.
I wonder if decision for stable syscalls was genius? Like imagine that Linux syscalls will become what C ABI is now. And there will be multiple compatible kernels, so you can choose any and run the same userspace.
Why would you want to support multiple? New versions should always be backwards compatible with older ones, so you'll always have the largest amount of compatibility by targeting the latest upstream. The real challenge comes with supporting applications that want features only available in forked kernels, which I guess could prompt wanting multiple kernels targeting the distinct ABIs.
Earlier quoted context omitted.
Looking at the code, it consists of long chains of get().unwrap().to_mut().unwrap().get() noise. Looks like coping with library design than ownership tacking. Also why Result >? Isn't Result already Option by itself? I guess that's why you need get().unwrap().to_mut() to get a value from Result > from an average function call?
>> Also why Result >? Isn't Result already Option by itself? No. I've written code that returns Result >. It was a wrapper for a server's query web API. The Result part determines whether the request succeeded and the response is valid. The Option part is because the parameter being queried might not exist. For example, if I ask the API for the current state of the user session with a given Session ID, but that Sessi…
Earlier quoted context omitted.
Looking at the code, it consists of long chains of get().unwrap().to_mut().unwrap().get() noise. Looks like coping with library design than ownership tacking. Also why Result >? Isn't Result already Option by itself? I guess that's why you need get().unwrap().to_mut() to get a value from Result > from an average function call?
>> Also why Result >? Isn't Result already Option by itself? No. I've written code that returns Result >. It was a wrapper for a server's query web API. The Result part determines whether the request succeeded and the response is valid. The Option part is because the parameter being queried might not exist. For example, if I ask the API for the current state of the user session with a given Session ID, but that Sessi…
Earlier quoted context omitted.
Otherwise is a decent language but what makes it difficult is the borrow semantics and lifetimes. Lifetimes are more complicated to get your head around. But then there's this Arc, Ref, Pinning and what not - how deep is that rabbit hole?
I don’t entirely agree, you can get used to the borrow checker relatively quickly and you mostly stop thinking about it. What tends to make Rust complex is advanced use of traits, generics, iterators, closures, wrapper types, async, error types… You start getting these massive semi-autogenerated nested types, the syntax sugar starts generating complex logic for you in the background that you cannot see but have to ke…