[HN Gopher] Asterinas: OS kernel written in Rust and providing L...
___________________________________________________________________
Asterinas: OS kernel written in Rust and providing Linux-compatible
ABI
Author : Klasiaster
Score : 340 points
Date : 2024-10-15 12:01 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tiffanyh wrote:
| OT: if you're interested in Asterinas, you might also be
| interested in Redox (entire OS written in Rust).
|
| https://www.redox-os.org/
| metaketa wrote:
| This is fascinating! Couldn't really find the kernel code but
| would love to know more about the applicability. I'm curious
| since seeing the Unikraft release that promised millisecond
| container boot times
| cmiller1 wrote:
| https://gitlab.redox-os.org/redox-
| os/kernel/-/tree/master/sr...
| snvzz wrote:
| Redox has a proper architecture, aka microkernel multiserver.
|
| Thus it is a much more interesting project.
| DoctorOW wrote:
| I love Redox as a project because while it still has a massive
| ways to go, it's the closest to being a new OS/Kernel that has
| the potential to make it to a viable daily driver.
| Windows/MacOS/Unix/Linux are all incredibly old by software
| standards and Redox is bringing some cool design decisions.
| spease wrote:
| What's the intended use case for this? Backend containers?
| Animats wrote:
| Makes a lot of sense for virtual machine containers. Inside a
| container inside a VM, you need far less operating system.
| akira2501 wrote:
| I personally dislike rust, but I love kernels, and so I'll always
| check these projects out.
|
| This is one of the nicer ones.
|
| It looks pretty conservative in it's use of Rust's advanced
| features. The code looks pretty easy to read and follow. There's
| actually a decent amount of comments (for rust code).
|
| Not bad!
| IshKebab wrote:
| Rust code is usually well commented in my experience.
| cies wrote:
| Instead of asking "what other languages and project
| (open/closed, big/small, web/mobile/desktop,
| game/consumerapp/bizapp) have you experience with as to come
| to this conclusion?" people down vote you.
|
| So lemme ask: what other languages and project (open/closed,
| big/small, web/mobile/desktop, game/consumerapp/bizapp) have
| you experience with as to come to this conclusion?
| ramon156 wrote:
| I expect the downvotes to be there because it's talking
| positively about rust, which is blasphemy! /j
| tracker1 wrote:
| I'm guessing a lot of any perception of a lack of
| comments or documentation in a rust codebase comes down
| to how new or green a developer is to rust.
|
| If you're just starting out or doing something relatively
| simple, your goal is to get something working. This is so
| true regardless of the language.
| iknowstuff wrote:
| for the downvoters: it's true, and it's because of rustdoc
| and doctests. comments become publicly browsable
| documentation, and any code contained within is run as a part
| of the test suite.
| 1oooqooq wrote:
| think the downvotes are because of relevance. point was not
| using advanced rust features, not being documented
| forks wrote:
| I don't see how the relevance is in question. GGGP said
| "There's actually a decent amount of comments (for rust
| code)." GGP seems to be responding to that parenthetical.
| cgh wrote:
| Javadoc pioneered this 25+ years ago and despite that,
| there's plenty of poorly-documented Java code out there.
| Orders of magnitude more of it than all of the Rust code in
| existence, in fact.
|
| Intuition tells me that Rust is young enough to attract a
| certain type of early adopter, the kind of programmer who
| is more likely to document their code well from the outset.
| wg0 wrote:
| 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?
| oneshtein wrote:
| Rust lifetime is just a label for a region of memory with
| various data, which is discarded at the end of its life time.
| When compiler enters a function, it creates a memory block to
| hold data of all variables in the function, and then discards
| this block at the exit from the function, so these variables
| are valid for life time of the function call only.
| KingOfCoders wrote:
| 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.
| Galanwe wrote:
| 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.
| netbsdusers wrote:
| 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
| guarantee for as long as you hold an RCU read-lock (this
| is the case in Linux with SLAB_TYPESAFE_BY_RCU). It is
| possible in some cases to be able to safely deal with
| references to objects where the "lifetime" of the
| referent has ended, but where by dint of it being
| guaranteed to be the same type of object, you can still
| do what you want to do.
|
| This comes in handy when you have a problem that commonly
| appears in kernels where you need to invert a typical
| lock ordering (a classic case is that the page fault
| codepath might want to lock, say, VM object then page
| queue, but the page-replacement codepath will want to
| lock page-queue then VM object.)
|
| Unfortunately it's hard to think of how the preconditions
| for these tricks could be formally expressed.
| andrewflnr wrote:
| Wouldn't you want the relevant Rust lifetime to be that
| of the type-stable memory block, not the individual
| "object" inside? I'm not that familiar with kernel
| programming, but that sounds a lot like an arena, and
| (IIRC) that's the approach with an arena.
| acomar wrote:
| I've found the opposite. every time I attempt to subvert
| the borrow checker, I eventually discover that I'm
| attempting to write a bug.
| jeroenhd wrote:
| Lifetime tracking and ownership are very difficult. That's
| why languages like C and C++ don't do it. It's also why
| those languages needs tons of extra validation steps and
| analysis tools to prevent bugs.
|
| Arc is nothing more than reference counting. C++ can do
| that too, and I'm sure there are C libraries for it. That's
| not an admission of anything, it's actually solving the
| problem rather than ignoring it and hoping it doesn't crash
| your program in fun and unexpected ways.
|
| Using Arc also comes with a performance hit because
| validation needs to be done at runtime. You can go back to
| the faster C/C++ style data exchange by wrapping your code
| in unsafe {} blocks, though, but the risks of memory
| corruption, concurrent access, and using deallocated memory
| are on you if you do it, and those are generally the whole
| reason people pick Rust over C++ in the first place.
| GoblinSlayer wrote:
| 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<Option<T>>? Isn't Result already Option by
| itself? I guess that's why you need
| get().unwrap().to_mut() to get a value from
| Result<Option<T>> from an average function call?
| LinXitoW wrote:
| If I ask my repository (backed by an sql db) to get a
| user, there might be 3 different scenarios I'm interested
| in:
|
| - Technical problem (like connection problems) means I
| don't know what's in the db
|
| - No technical problem, but no user entry
|
| - No technical problem, and a user entry
|
| You need the Result for the technical problems, and the
| Option for whether there's a user entry or not.
| GoblinSlayer wrote:
| Surely Result is supposed to hold both system errors and
| business errors.
| thesuperbigfrog wrote:
| >> Also why Result<Option<T>>? Isn't Result already
| Option by itself?
|
| No. I've written code that returns Result<Option<T>>. 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 Session ID does not exist, then the Rust
| wrapper could return OK(None) meaning that the request
| succeeded, but that no such session was found.
| GoblinSlayer wrote:
| Presumably missing session is an alternative scenario and
| thus should be reported as an error, then you match and
| handle this error. Your design complicates the common
| scenario: in case of valid session you need double
| unwrap, cf File::open that could return
| Result<Option<File>> if file is not found.
| thesuperbigfrog wrote:
| >> Presumably missing session is an alternative scenario
| and thus should be reported as an error
|
| But in this case, a query using an invalid session ID is
| not an error. It is asking for details about something
| that does not exist.
|
| >> cf File::open that could return Result<Option<File>>
| if file is not found.
|
| This type of query is not like File::open which gets a
| handle to a resource. Trying to get a handle to a
| resource that does not exist is an error.
|
| This type of query is read-only and does not allocate any
| resources or prepare to do anything with the session.
|
| It simplifies the control flow because it distinguishes
| between errors in completing a query versus the presence
| or absence of items returned from the query.
| oniony wrote:
| Result is whether an operation returned an error or not.
| Option is whether you have a value or no value.
| thesuperbigfrog wrote:
| Exactly.
|
| That is why a query that successfully returns no items
| can be represented as Ok(None).
|
| A successful query with items returned would instead be
| Ok(Vec<Item>).
|
| An error in the completing the query (for example,
| problem with the database), would be Err(DatabaseError)
| or Err(SomeOtherError).
| GolDDranks wrote:
| It's not just difficult, sometimes it's impossible to
| statically know a lifetime of a value, so you must
| dynamically track it. Arc is one of such tools.
| lmm wrote:
| If tracking lifetimes is simple 90% of the time and complex
| 10% of the time, maybe a tool that lets you have them
| automatically managed (with some runtime overhead) that 10%
| of the time is the right way forward.
| tracker1 wrote:
| Then you can use a language and runtime like C# or Java.
| Or you can use patterns like Go promotes.
|
| There are lots of options if you want.
| surajrmal wrote:
| Arc usually means you've not structured your code to have
| clear lifetimes where one object clearly outlives another.
| Typically I see c++ applications avoid it but actually
| suffer from bugs due to the same structural deficiencies.
| They said, I think it's almost always possible to to avoid
| it if you try hard enough. With async you need to use
| structured concurrency.
| baq wrote:
| If you're writing C and don't track ownership of values,
| you're in a world of hurt. Rust makes you do from day one
| what you could do in C but unless you have years of
| experience you think it isn't necessary.
| metalloid wrote:
| It was true until LLMs arrive. Feature compilers + IDEs can
| be integrated with LLMs to help programmers.
|
| Rust was a great idea, before LLMs, but I don't see the
| motivation for Rust when LLMs can be the solution initial
| for C/C++ 'problems'.
| baq wrote:
| On the contrary LLMs make using safe but constraining
| languages easier - you can just ask it how to do what you
| want in Rust, perhaps even by asking it to translate
| C-ish pseudocode.
| smolder wrote:
| Relying on LLMs to code for you in no way solves the
| safety problem of C/C++ and probably worsens it.
| BrainInAJar wrote:
| probably?
|
| even if the LLM is trained on flawless C code (which it
| isn't) it still has no way of reasoning about a complex
| system, it's just "what token is statistically most
| likely to come next"
| ulbu wrote:
| Rust compiler checks things for you. People trust the
| Rust compiler because it enforces rules they want, so
| people don't have to be in its place. Your suggestion is
| to be that checker to LLM-generated code. Back to square
| one.
| wg0 wrote:
| Okay, I think it is is more like Typescript. You hate it
| but one day you just write small JS program and convert it
| to Typescript to discover that static analysis alone had so
| many code paths revealed that would have resulted in
| uncaught errors and then you always feel very uncomfortable
| writing plain Javascript.
|
| But what about tools like valgrind in context of C?
| badmintonbaseba wrote:
| Valgrind is great, especially if you write extensive
| tests and you actually run them through it regularly. And
| even then, it does not prove the absence of any kind of
| bugs. Safe rust has strong guarantees.
| baq wrote:
| You probably should run your rust programs through
| valgrind regardless. Rust is safer than C, but any unsafe
| code drops you to approximately C level of safety and any
| C FFI calls are obviously outside of rust's control or
| responsibility.
| rcxdude wrote:
| Valgrind can only tell you about issues that your
| testcases exercise. It doesn't provide the same
| guarantees as static checking of memory safety
| invariants. But, if you're really concerned (especially
| about unsafe code), belt-and-bracers is a good strategy,
| and valgrind will work with rust binaries as well. Rust
| also has a tool called MIRI which can similarly flag up
| issues in testcases (it's effectively an interpreter for
| the intermediate representation in the compiler, and it
| can detect undefined behaviour even if the compiled
| assembly would happen to look OK. Still has the same
| limitation of needing extensive testcases though)
| tracker1 wrote:
| A few years ago I was worrying on a Byzantine mess of a
| JS project. I converted everything to TS for the sole
| reason of somewhat safely refactoring the project as a
| whole.
|
| There was so little trust in the fragility of the
| original, it took a few months to convince everyone the
| refactored TS branch was safe.
|
| After that, feature development was a lot faster in terms
| of productivity again.
| jimbomins wrote:
| frama-c
| oersted wrote:
| 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 keep in mind.
|
| It's tempting to use the advanced type system to encode and
| enforce complex API semantics, using Rust almost like a
| formal verifier / theorem prover. But things can easily
| become overwhelming down that rabbit hole.
| jonathanstrange wrote:
| It's just overengineered. Many Rust folks don't realize it
| because they come from C++ and suffer from Stockholm
| Syndrome.
| junon wrote:
| Context: I'm writing a novel kernel in Rust.
|
| Lifetimes aren't bad, the learning curve is admittedly a bit
| high. Post-v1 rust significantly reduced the number of places
| you need them and a recent update allows you to elide them
| even more if memory serves.
|
| Arc isn't any different than other languages, not sure what
| you're referring to by ref but a reference is just a pointer
| with added semantic guarantees, and Pin isn't necessary
| unless you're doing async (not a single Pin shows up in the
| kernel thus far and I can't imagine why I'd have one going
| forward).
| mcherm wrote:
| Would you not want to use Pin when sharing memory with a
| driver or extension written in a different language (eg:
| C)?
| bombela wrote:
| Pin is a pure compile time abstraction for a single
| problem: memory safety of self referential struct.
|
| Pin leverages the type system to expose to the programmer
| receiving a pointer to a Pin'ned object, that this object
| has some pointer on itself (a self referencial struct).
| You better be mindful not to move this object to a
| different memory location unless you know for sure that
| it is safe to do so. The Pin abstraction makes it harder
| to forget; and easier to notice during code review; by
| forcing you to use the keyword unsafe for any operations
| on the pinned object that could move it around.
|
| In C, there is no such way to warn the programmer besides
| documentation. It is up to the programmer to be very
| careful.
| depressedpanda wrote:
| From the README:
|
| > Currently, Asterinas only supports x86-64 VMs. However, our aim
| for 2024 is to make Asterinas production-ready on x86-64 VMs.
|
| I'm confused.
| MattPalmer1086 wrote:
| Yeah, I had to read that a few times... I think they just mean
| it isn't production ready yet, but that's what they are aiming
| for.
| favorited wrote:
| Sounds like their goal is to improve their x86-64 support
| before implementing other ISAs.
| nurb wrote:
| It's clearer from the book roadmap:
|
| > By 2024, we aim to achieve production-ready status for VM
| environments on x86-64. > In 2025 and beyond, we will expand
| our support for CPU architectures and hardware devices.
|
| https://asterinas.github.io/book/kernel/roadmap.html
| convolvatron wrote:
| it would be nice to know how much userspace it supports.
| supporting the dynamic loader, reasonable futexes, epoll,
| signals, uring are all big milestones
| throw4950sh06 wrote:
| Check it out https://asterinas.github.io/book/kernel/linux-
| compatibility....
| wrs wrote:
| I think it's "Currently, Asterinas only supports x86-64 VMs.
| However, [rather than working on additional architectures this
| year,] our aim for 2024 is to make Asterinas production-ready
| on x86-64 VMs."
| None4U wrote:
| Distinction here is between "supports" and "production-ready
| on", not "x86-64" and "x86-64"
| netbsdusers wrote:
| They lack essential things for a kernel that could be used in
| production, viz. not kernel panicing during out-of-memory
| conditions, not an easy thing to retrofit when you have
| designed without consideration of it. It will probably take a
| bit more than 2 and a half months to rectify that.
|
| https://github.com/asterinas/asterinas/issues/669
| empath75 wrote:
| https://github.com/rust-lang/rust/issues/48043
|
| They've been working on it for a while so they can get rust
| into the linux kernel
| valunord wrote:
| I like what they're working towards with V in Vinix as well.
| Exciting times to see such things with ABI compat with Linux
| opening new paradigms.
| Alexsky2 wrote:
| I'll mention another OS written in Rust, Twizzler:
| https://twizzler.io/
|
| Its more of a research OS but still cool.
| Teever wrote:
| And I'll mention another one that a friend of mine is working
| on: uxrt
|
| https://gitlab.com/uxrt
| treeshateorcs wrote:
| https://www.youtube.com/watch?v=3AQ5lpXujGo Asterinas: A safe
| Rust-based OS kernel for TEE by H. Tian & C. Song (Ant Group &
| Intel) | OC3 2024
| gghh wrote:
| Exactly. I see elsewhere in this page people comparing this
| project to Linus Torvalds starting an OS in his dorm room while
| studying CS. Like these were _" young and clueless"_ devs
| writing an OS for fun.
|
| From the looks of it, this seems like a serious corporate
| backed project made by employees of the Ant Group, the chinese
| fintech giant. A more fair comparison would be with Google's
| Fuchsia OS (defunct) or Huawei's HarmonyOS. It may succeed, it
| may fail, but it's nothing like a couple of kids doing a
| passion project to learn Rust.
| justmarc wrote:
| I'm interested in these kind of kernels to run very high
| performance network/IO specific services on bare metal, with
| minimal system complexity/overheads and hopefully better
| (potential) stability and security.
|
| The big concern I have however is hardware support, specifically
| networking hardware.
|
| I think a very interesting approach would be to boot the machine
| with a FreeBSD or Linux kernel, just for the purposes of hardware
| as well as network support, and use a sort of Rust OS/abstraction
| layer for the rest, bypassing or simply not using the originally
| booted kernel for all user land specific stuff.
| treeshateorcs wrote:
| i might be wrong but if it's ABI compatible the same drivers
| will work?
|
| p.s.: i was wrong
|
| >While we prioritize compatibility, it is important to note
| that Asterinas does not, nor will it in the future, support the
| loading of Linux kernel modules.
|
| https://asterinas.github.io/book/kernel/linux-compatibility....
| justmarc wrote:
| No, it means you can run Linux userland/apps on this kernel,
| to the level/depth which they currently support of course.
|
| They might not yet implement everything that's needed to boot
| a standard Linux userland but you could say boot straight
| into a web server built for Linux, instead of booting into
| init for example.
| bicolao wrote:
| They mention this in https://github.com/asterinas/asterinas/b
| lob/2af9916de92f8ca1...
|
| > While we prioritize compatibility, it is important to note
| that Asterinas does not, nor will it in the future, support
| the loading of Linux kernel modules.
| justmarc wrote:
| It's a lot "simpler" to support a Linux userland as that
| means one needs to "just" emulate all the Linux syscalls,
| than to implement the literally countless internal APIs
| needed for drivers etc, as that would otherwise mean
| literally reimplementing the whole Linux kernel and that's
| neither realistic, nor too useful.
| Jyaif wrote:
| > emulate all the Linux syscalls
|
| and emulate the virtual filesystems (/proc/...)
| mgerdts wrote:
| And that's not all that simple, as has been experienced
| by Solaris (never released(?) Linux branded zones,
| illumos (lx brand), and Windows (WSL1) developers that
| have tried to make existing kernels act like Linux.
|
| It's probably easier if the kernel's key goal is to be
| compatible with the Linux ABI rather than being
| compatible with its earlier self while bolting on Linux
| compatibility.
| yjftsjthsd-h wrote:
| Linux doesn't even maintain ABI compatibility with _itself_ ,
| nobody else is going to manage it. The possibility that might
| work is there's a couple projects that maintain just enough A
| _P_ I compatibility to reuse driver code from Linux (IIRC
| FreeBSD does this for some graphics drivers). But even then
| you're gambling with whether Linux decides to change
| implementation details one day, since internal APIs
| explicitly aren't stable.
| bcrl wrote:
| The Linux kernel community takes ABI compatibility for
| userland very seriously. That developers in userland are
| frequently unwilling to understand issues surrounding ABI
| stability is not the fault of the Linux kernel.
| yjftsjthsd-h wrote:
| Oh sure, the user-space ABI is stable; I meant kernel-
| space. Although I realize now that I failed to write that
| explicitly.
| bcrl wrote:
| The past 30 years of the Linux kernel's evolution has
| proven that there is no need for a stable kernel ABI.
| That would make refactoring, adding new features and
| porting to new platforms exceedingly difficult. Pretty
| much all of the proprietary kernel modules have either
| become open source or been replaced by open source
| replacements. The Linux community doesn't need closed
| source kernel modules for VMWare anymore, and even Nvidia
| has finally given up on their closed source GPU drivers.
| Proprietary Linux kernel modules have no place in the
| modern world.
| vlovich123 wrote:
| > even Nvidia has finally given up on their closed source
| GPU drivers.
|
| lol. No. They just added a CPU and then offloaded all the
| closed source userspace driver code to it leaving behind
| the same dumb open sourceable kernel driver shim as
| before (ie instead of talking to userspace it talks to
| the GPU's CPU).
|
| > The past 30 years of the Linux kernel's evolution has
| proven that there is no need for a stable kernel ABI.
|
| What the last 30 years have shown is that there is
| actually a need for it, otherwise DKMS wouldn't be a
| thing. Heck, intel's performance profiler can't keep up
| with the kernel changes which means you get to pick
| running an up to date kernel or be able to use the open
| source out-of-tree kernel module. The fact that Linux is
| alone in this should make it clear it's wrong. Heck
| Android even wrote their own HAL to try to make it
| possible to update the kernel on older devices. It's an
| economics problem that the Linux kernel gets to pretend
| doesn't exist but it's a bad philosophical position. It's
| possible to support refactoring and porting to new
| platforms while providing ABI compatibility and Linux is
| way past the point where it would even be a minor
| inconvenience - all the code has ossified quite a bit
| anyway.
| GoblinSlayer wrote:
| It depends on your goals, but at least Torvalds believes
| driver availability is important and unstable ABI is
| known to hinder driver availability.
| lmm wrote:
| > The past 30 years of the Linux kernel's evolution has
| proven that there is no need for a stable kernel ABI.
|
| My experience of using Linux and having devices that used
| to work become unsupported suggests just the opposite.
| dathinab wrote:
| in general the ABI is kernel<->user space while the ABI (and
| potentially even API) on the inside (i.e. for drivers) can
| change with every kernel version (part of why it's so
| important to maintain drivers in-tree)
| cgh wrote:
| If you want truly high-performance networking, you can bypass
| the kernel altogether with DPDK. So you don't have to worry
| about alternative kernels for other tasks at all. On the
| downside, DPDK takes over the NIC entirely, removing the kernel
| from the equation, so if you need the kernel to see network
| traffic for some reason, it won't work for you.
|
| You can check out hardware support here:
| https://core.dpdk.org/supported/nics/
| jauntywundrkind wrote:
| This was true a decade ago, with modern io_uring dpdk is
| probably an anti-pattern.
| cgh wrote:
| Interesting, it's been awhile since I looked at this stuff
| so I did a little searching and found this:
| https://www.diva-
| portal.org/smash/get/diva2:1789103/FULLTEXT...
|
| Their conclusion is io_uring is still slower but not by
| much, and future improvements may make the difference
| negligible. So you're right, at least in part. Given the
| tradeoffs, DPDK may not be worth it anymore.
| loeg wrote:
| There are also just a bunch of operational hassles with
| using DPDK or SPDK. Your usual administrative commands
| don't work. Other operations aren't intermediated by the
| kernel -- instead you need 100% dedicated application
| devices. Device counters usually tracked by the kernel
| aren't. Etc. It can be fine, but if io_uring doesn't add
| too much overhead, it's a lot more convenient.
| renox wrote:
| Not by much?? You're exaggerating..
| guenthert wrote:
| That's an interesting and valuable study. I was slightly
| disappointed though that only a single host was used in
| the 'network' performance tests:
|
| "SR-IOV was used on the NIC to enable the use of virtual
| functions, as it was the only NIC that was available
| during the study for testing and therefore the use of
| virtual functions was a necessity for conducting the
| experiments."
| guenthert wrote:
| "io_uring had a maximum throughput of 5.0 Gbit/s "
|
| Wut? More than 10 years ago, a cheap beige box could
| saturated a 1Gbps link with a kernel as it came from e.g.
| Debian w/o special tuning. A somewhat more expensive box
| could get a good share of a 10Gbps link (using Jumbo
| frames), so these new results are, er, somewhat
| underwhelming.
| rcxdude wrote:
| Packet size does affect the throughput quite a lot,
| though. The tests in the paper are without jumbo frames
| (I do agree though, that the results in that paper can't
| really be described as 'close', when io_uring is 1/5 the
| speed, only achieves that at the largest packet size, and
| has much more packet loss under those conditions)
| monocasa wrote:
| I'm not sure that's true for a good chunk of the workloads
| that dpdk really shines on.
|
| A lot of the benefit of dpdk is colocating your data and
| network stack in the same virtual memory context. io_uring
| I can see getting you there if you have you're serving
| fixed files as a cdn kind of like netflix's appliances, but
| for cases where you're actually doing branchy work on the
| individual requests, dpdk is probably a little easier to
| scale up to the faster network cards.
| GoblinSlayer wrote:
| If you use io_uring, you're subject to vulnerabilities in
| kernel network stack which you have no control over.
| not_a_dane wrote:
| that's rare.
| nijave wrote:
| Couldn't you just boot the Linux kernel directly and launch a
| generic app as pid 1 instead of a full blown init system with a
| bunch of daemons?
|
| That's basically what you're getting with Docker containers and
| a shared kernel. AWS Lambda is doing something similar with
| dedicated kernels with Firecracker VMs
| mjevans wrote:
| Yes, you can. You can even have a different Pid 1 configure
| whatever and then replace it's core image with the new Pid 1.
| justmarc wrote:
| Yes, but I wanted to bypass having the complexity of the
| Linux kernel completely, too.
|
| Basically single app directly to network (the world) and as
| little as possible else in between.
| afr0ck wrote:
| Linux kernel is not complex. Most of the code runs lock-
| free. For example, the slab allocator in the kernel uses
| only a single double_cmpxhg instruction to allocate an
| object via kmalloc(). The algorithm scales to any number of
| CPUs and has NUMA awareness. Basically, the most
| concurrent, lowest allocation latency allocator you can get
| in the market, which also returns the best objects for the
| requesting process on big memory systems.
|
| The complexity on the other hand is architectural and
| logical to achieve scale to hundreds of CPUs, maximise
| bandwidth and reduce latency as much as possible.
|
| Any normal Rust kernel will either have issues scaling on
| multi-cores or use tax-heavy synchronisation primitives.
| The kernel RCU and lock-free algorithm took a long time to
| be discovered and become mature and optimised aggressively
| to cater for the complex modern computer architectures of
| out-of-order execution, pipelining, complex memory
| hierarchies (especially when it comes to caching) and NUMA.
| sshine wrote:
| A new kernel can never beat legacy kernels on hardware
| support.
|
| To reach a useful state, you only need to be highly
| performant on a handful of currently popular server
| architectures.
|
| > _Any normal Rust kernel will either have issues scaling
| on multi-cores or use tax-heavy synchronisation
| primitives._
|
| I'm not sure how that applies to Asterinas. Is Asterinas
| any normal Rust kernel?
|
| https://asterinas.github.io/book/kernel/the-framekernel-
| arch...
| protoman3000 wrote:
| Why don't you just use a SmartNIC and P4? It won't get faster
| than running on the NIC itself
| jackhalford wrote:
| The building process happens in a container?
|
| > If everything goes well, Asterinas is now up and running inside
| a VM.
|
| Seems like the developers are very confident about it too
| havaker wrote:
| The license choice is explained with the following:
|
| > [...] we accommodate the business need for proprietary kernel
| modules. Unlike GPL, the MPL permits the linking of MPL-covered
| files with proprietary code.
|
| Glancing at the readme, it also looks like they are treating it
| as a big feature:
|
| > Asterinas surpasses Linux in terms of developer friendliness.
| It empowers kernel developers to [...] choose between releasing
| their kernel modules as open source or keeping them proprietary,
| thanks to the flexibility offered by MPL.
|
| Can't wait to glue some proprietary blobs to this new, secure
| rust kernel /s
| yjftsjthsd-h wrote:
| I'm curious about the practical aspect: Are they going to
| freeze a stable driver ABI, or are they going to break
| proprietary drivers from time to time?
| gpm wrote:
| Considering their OS as a framework approach I would guess
| they are more likely to expose a stable _API_ than a stable
| ABI. Which also plays well with the MPL license (source file
| based) rather than something like the LGPL (~linking based).
| throw4950sh06 wrote:
| This is the most interesting new OS I have seen in many
| years.
| cryptonector wrote:
| > Linux-compatible ABI
|
| There's no specification of that ABI, much less a compliance test
| suite. How complete is this compatibility?
| Klasiaster wrote:
| Here is a list of implemented syscalls, but of course each
| checked one could still be slightly incompatible:
|
| https://asterinas.github.io/book/kernel/linux-compatibility....
| cryptonector wrote:
| There's also tons of ioctls and /proc and what not.
| mgerdts wrote:
| 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/
| cryptonector wrote:
| LTP really needs to be a part of Linux itself.
| Klasiaster wrote:
| There was also the similar project Kerla1 but development
| stalled. Recently people argued that instead of focusing on Rust-
| for-Linux it would be easier to create a drop-in replacement like
| these two. I wonder if there are enough people interested to make
| this happen as a sustained project.
|
| 1 https://github.com/nuta/kerla/
| kelnos wrote:
| > _Recently people argued that instead of focusing on Rust-for-
| Linux it would be easier to create a drop-in replacement like
| these two_
|
| I guess it depends on what they mean by "easy". Certainly it's
| easier in the sense that you can just write code all day long,
| and not have to deal with the politics about Rust inside Linux,
| or deal with all the existing C interfaces, finding ways to
| wrap them in Rust in good, useful ways that leverage Rust's
| strengths but don't make it harder to evolve those C interfaces
| without trouble on the Rust side.
|
| But the bulk of Linux is device drivers. You can build a kernel
| in Rust (like Asterinas) that can run all of a regular Linux
| userland without recompilation, and I imagine it's maybe not
| even that difficult to do so. But Asterinas only runs on x86_64
| VMs right now, and won't run on real hardware. Getting to the
| point where it could -- especially on modern hardware -- might
| take years. Supporting all the architectures and various bits
| of hardware that Linux supports could take decades. I suppose
| limiting themselves to three or four architectures, and only
| supporting hardware made more recently could cut that down. But
| still, it's a daunting project.
| weinzierl wrote:
| 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 they will not
| replace Linux as we have it today.
|
| (Asterinas, from what I understood, doesn't claim to replace
| Linux, but it a common expectation.)
| loeg wrote:
| More recently, in a similar vein:
|
| > Torvalds seemed optimistic that "some clueless young person
| will decide 'how hard can it be?'" and start their own
| operating system in Rust or some other language. If they keep
| at it "for many, many decades", they may get somewhere; "I am
| looking forward to seeing that". Hohndel clarified that by
| "clueless", Torvalds was referring to his younger self; "Oh,
| absolutely, yeah, you have to be all kinds of stupid to say 'I
| can do this'", he said to more laughter. He could not have done
| it without the "literally tens of thousands of other people";
| the "only reason I ever started was that I didn't know how hard
| it would be, but that's what makes it fun".
|
| https://lwn.net/Articles/990534/
| ackfoobar wrote:
| > Hohndel clarified that by "clueless", Torvalds was
| referring to his younger self
|
| As the saying goes "We do this not because it is easy, but
| because we thought it would be easy."
|
| Occasionally these are starts of great things.
| nickpsecurity wrote:
| Sometimes, we do such things because it's hard. We enjoy
| the challenge. Those that succeed are glad to make it, too.
| dathinab wrote:
| but most times, even in such cases, people underestimate
| or not estimate at all the "hard task they do as a
| challenge" it's kinda part of the whole thing
| BodyCulture wrote:
| Sometimes we just don't know if a person that started
| something did know how hard it would be or not. Sometimes
| it is not possible to know how hard things can be or not.
|
| Generally this is a very interesting question hat could
| be discussed in a very long thread, but still the reader
| will not get any value from it.
| m463 wrote:
| "You are enthusiastic and write kernel device drivers in
| rust. Write a device driver for an Intel i350 4 Port gigabit
| ethernet controller"
| NetOpWibby wrote:
| Some future VC-funded company will unironically have this
| same requirement
| m463 wrote:
| It wasn't a requirement, it was a prompt :)
| NetOpWibby wrote:
| Haha damn, it's so obvious now. I should be asleep.
| sshine wrote:
| LLMs are notoriously bad at improvising device drivers in
| no-std Rust.
| Y_Y wrote:
| Claude Sonnet 3.5 seemed happy enough to do it, and the
| start looked promising Absolutely! Let's
| dive into writing a device driver for the Intel i350 4 Port
| Gigabit Ethernet Controller using Rust. This is an exciting
| project that combines low-level hardware interaction with
| the safety and performance benefits of Rust. I'll create a
| basic structure for our driver, focusing on the key
| components needed to interact with the device.
| #![no_std] #![feature(abi_x86_interrupt)]
| ...
|
| but I'm not qualified to judge the quality from eyeballing
| and I'm certainly not going to go to the trouble of trying
| to test it.
| m463 wrote:
| "You are a pessimistic and pedantic tester of device
| drivers. test the following device driver for conformance
| to the rust language, to the kernel api, to hardening
| standards, judging the quality following iso 29119."
| senko wrote:
| You jest, but I believe @tptacek is using an LLM (ChatGPT?)
| to understand the details of various Linux kernel subsystem
| and has said it works quite well for the task.
|
| It's not a great jump from that to "port Linux device
| driver for XYZ to this new OS in Rust". Won't be perfect
| but a lot less hassle than doing it from scratch.
| linsomniac wrote:
| I feel like there's a potentially large audience for a kernel
| that targets running in a VM. For a lot of workloads, a simple
| VM kernel could be a win.
| yjftsjthsd-h wrote:
| How is that different from Linux with all virtio drivers?
| (You can just not compile real hardware drivers)
| m463 wrote:
| I would imagine that virtualized device drivers would have
| a well-defined api and vastly simplified logic.
| yjftsjthsd-h wrote:
| I imagine they do. But given that Linux has those simple
| drivers, why not use them?
| prmoustache wrote:
| Shouldn't we start building hardware that have a builtin
| translation layer that makes them driveable by virtio
| drivers themselves? At least for the most capabilities?
| lmm wrote:
| The point is it would be better than Linux in whatever way
| that was the reason you were writing it, but you don't have
| to write hundreds of different device drivers to make your
| cool new kernel usable.
| rcxdude wrote:
| If it's written in rust, you might expect less security
| vulnerabilities (especially if the codebase is also
| smaller: NB this is potentially counterbalanced by the many
| eyes on linux). Maybe there would be some extra features
| you find useful.
| pjmlp wrote:
| This is already the reality today with native cloud
| computing, managed runtimes.
|
| It doesn't matter how the language gets deployed, if the
| runtime is on a container, a distroless container, or
| directly running on an hypervisor.
|
| The runtime provides enough OS like services for the
| programming language purposes.
| prmoustache wrote:
| this x1000
|
| Provided you have virtio support you are ticking a lot of
| boxes already.
| lmm wrote:
| Those workloads would probably be better off as unikernels
| that can run directly on the VM, avoiding the question of
| which kernel to use entirely.
| rcxdude wrote:
| There's a difference between "want to run an application
| with as little extra move parts on a VM" and "want to take
| an existing system and swap out for a kernel with some
| better properties, even if it means needing to run it in a
| VM"
| eyberg wrote:
| This is a very large rationale for what we are building with
| https://nanos.org .
| mdhb wrote:
| Also this mysterious new Fuchsia OS from Google is also
| shooting for full Linux compatibility and is about to show up
| in Android, I think this is a much more realistic path of the
| next generation of operating systems that have a real chance to
| replace Linux but who knows what their actual plans are here at
| the moment but I don't believe for a moment that that project
| is dead in any way.
| lifty wrote:
| Can you give more details about it being used in Android? I
| thought they started using it in some small devices like nest
| but haven't heard anything about Android
| mdhb wrote:
| It's about to turn up inside Android running in a VM [1]
| but it was less clear exactly for what purpose.
|
| My theory is that this is essentially a long term project
| to bring the core of Chrome OS and Android to rely on
| Fuschia for its core which gives them syscall level
| compatibility with what they both use at the moment and
| that they would both essentially sit as products on top of
| that.
|
| This is essentially the exact strategy they used if I
| remember correctly with the Nest devices where they swapped
| out the core and left the product on top entirely
| unchanged. Beyond that in a longer term scenario we might
| also just see a Fuchsia OS as a combined mobile / desktop
| workstation setup and I think part of that is also why we
| are seeing ChromeOS starting to take a dependency on
| Android's networking stack as well right now.
|
| [1] https://www.androidauthority.com/microfuchsia-on-
| android-345...
| vbezhenar wrote:
| 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.
| surajrmal wrote:
| 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.
| vbezhenar wrote:
| You can ask the same question about libc, yet there are
| several competing implementations. Yes, compatibility is
| not perfect and there are applications which won't work
| on musl, but still plenty of applications do.
| GoblinSlayer wrote:
| Just ask an AI to riir linux drivers. Anybody tried it?
| phlip9 wrote:
| Super cool project. Looks like the short-term target use-case is
| running a Linux-compatible OS in an Intel TDX guest VM with a
| significantly safer and smaller TCB. Makes sense. This way you
| also postpone a lot of the HW driver development drudgery and
| instead only target VM devices.
| hkalbasi wrote:
| > In the framekernel OS architecture, the entire OS resides in
| the same address space (like a monolithic kernel) and is required
| to be written in Rust. However, there's a twist---the kernel is
| partitioned in two halves ... the unprivileged Services must be
| written exclusively in safe Rust.
|
| Unprivileged services can exploit known compiler bugs and do
| anything they want in safe Rust. How this affects their security
| model?
| rcxdude wrote:
| I think it's not so much intended as a "you can allow arbitrary
| untrusted code to run as an unprivileged service" and more "a
| buggy unprivileged service won't compromise the whole system".
| snvzz wrote:
| I looked into the architecture. It turns out to be monolithic
| with marketing[0].
|
| Sure is a lot of text to say: We try to use unsafe as little as
| possible.
|
| Which is the minimum you'd expect anyways -\\_(tsu)_/-
|
| 0. https://asterinas.github.io/book/kernel/the-framekernel-
| arch...
| netbsdusers wrote:
| It's just what we used to call a "layered architecture".
| exabrial wrote:
| 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
| abstraction they are working with. Unless you're comparing
| something rating Ruby vs RiscV assembly, it's just hocus-pocus.
| ozgrakkurt wrote:
| Everyone says what they are used to is better or more
| productive. Even in assembly vs ruby, some stuff are much
| easier in assembly and maybe impossible in ruby afaik
| exabrial wrote:
| I'm aging myself, but ~17 years ago I was in San Diego for a
| conference. There was a table level competition to see who
| could write the fastest program in 20 minutes (we were doing
| a full text search of a 'giant' 5g file). One of the guys at
| the table wrote some SPARC assembly to optimize character
| matching that was a hotspot like he was speaking French.
|
| Ah good times.
| kelnos wrote:
| > _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
| interesting. Certainly matching behavior and semantics can be
| tricky sometimes, I 'm sure. And I wouldn't be surprised if the
| initial implementation of some things (like io_uring, for
| example, if it's even supported yet) might be primitive and
| poorly optimized, or might even use other syscalls to do their
| work.
|
| But it's doable. While Linux's _internal_ ABI is unstable, the
| syscall interface is sacred. One of Torvalds ' golden rules is
| you don't break userspace.
|
| [0] https://filippo.io/linux-syscall-table/
| JoshTriplett wrote:
| > 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.
|
| 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.
| jmmv wrote:
| > I think this looks incredible. Like how does one create a
| compatible abi _for all of linux_??? Wow!
|
| FWIW that's what the Linux compatibility layer in the BSDs does
| and also what WSL 1 did (https://jmmv.dev/2020/11/wsl-lost-
| potential.html).
|
| It's hard to get _everything_ perfectly right but not that
| difficult to get most of it working.
| NewJazz wrote:
| IIRC Fuschia has something similar. And maybe Redox?
| dathinab wrote:
| Idk. Asahi Linux GPU driver breaks all "common sense" of "how
| fast a reliable usable feature rich driver" was produced by a
| small 3rd party team.
|
| The company I work for has both rust and python projects
| (through partially pre "reasonable python type linting" using
| mypy and co.) and the general consensus there is "overall" rust
| is noticeable more productive (and stable in usage/reliable),
| especially if you have code which changes a lot.
|
| A company I worked previous for had used rust in the very early
| days (around 1.0 days) and had one of this "let's throw up a
| huge prototype code base in a matter of days and then rewrite
| it later" (basically 90% of code had huge tech dept). But that
| code base stuck around way longer then intended, caused way
| less issues then expected. I had to maintain it a bit and in my
| experience with similar code in Python and Js (and a bit Jave)
| I expected it to be very painful but surprisingly it wasn't,
| like at all.
|
| Similar comparing my experience massive time wastes due to
| having to debug soundness/UB issues in Rust, with experiences
| in C/C++ it's again way more productive.
|
| So as long as you don't do bad stuff like over obsessing with
| the type system everything in my experience tells me using Rust
| is more productive (for many tasks, definitely not all task,
| there are some really grate frameworks doing a ton of work for
| you in some languages against which the rust ecosystem atm.
| can't compete).
|
| ---
|
| > Most productive language for a developer is the one they
| understand what is happening one layer below the level of
| abstraction they are working with.
|
| I strongly disagree, the most productive language is the one
| where the developer doesn't have to care much about what
| happens in a layer below in most cases. At least as long as you
| don't want obsess over micro optimizations not being worth the
| time and opportunity cost they come with for most companies/use
| cases.
| xiaodai wrote:
| Lol. I am Malaysian Chinese but I honestly don't think anyone
| will put into production a Chinese made kernel. The risk is too
| high, same as no one will use a Linux distro coming out of
| Russian, Iran or NK. It's just cultural bias in the west.
| throw4950sh06 wrote:
| You're wrong. A lot of Chinese code and hardware is in
| production in the west. Huawei networking hardware is
| widespread, for example.
| tredre3 wrote:
| > Huawei networking hardware is widespread
|
| That's an interesting example because Huawei equipment is
| currently being removed by several Western countries (UK,
| Canada, US, Germany) specifically because it's Chinese.
|
| https://www.nytimes.com/2024/07/11/business/huawei-
| germany-b...
|
| https://www.cbc.ca/news/politics/huawei-5g-decision-1.631083.
| ..
|
| https://www.gov.uk/government/news/huawei-to-be-removed-
| from...
|
| https://www.reuters.com/business/media-telecom/us-open-
| progr...
| cozzyd wrote:
| When we got a license for a private LTE network in the
| middle of the Greenland ice sheet, the one stipulation was
| we couldn't use Huawei equipment...
| gpm wrote:
| Supposing it caught on... which do you think is riskier?
| Running an OS written in mostly memory safe code that somewhat
| might have tried to slip a backdoor in, or running an OS
| written in mostly memory unsafe code that has a long history of
| vulnerabilities and the Chinese almost certainly know about a
| vulnerability in.
|
| If this catches on and has generally been subject to
| significant third party code review with positive results, I'm
| not sure any backdoor is lower cost to use than an equivalent
| linux vulnerability. To be fair, I'm not sure it isn't either.
| wg0 wrote:
| Side question - I have always wondered how a Linux system is
| configured at the lowest level?
|
| Let's take example of network. There's IP address, gateway, DNS,
| routes etc. Depending on distribution we might see something like
| netplan reading config files and then calling ABI functions?
|
| Or Linux kernel directly also reads some config files? Probably
| not...
| NewJazz wrote:
| Linux kernel as much as possible tries not to parse or read
| external data (besides stuff like acpi tables, device trees,
| hardware registers). For networking, you might look at the
| iproute codebase to see how they do things like bring a network
| device up, or create a bridge device, add a route, et cetera.
|
| Edit: looks like iproute2 uses NETLINK, but non-networking
| tools might use syscalls or device ioctls.
|
| https://en.m.wikipedia.org/wiki/Netlink
| wiz21c wrote:
| > Linux-compatible ABI
|
| Does it mean it can re-use the drivers written for hardware to
| run with linux ?
| dezgeg wrote:
| No. There is no stable ABI nor API for in-kernel device
| drivers.
| eptcyka wrote:
| No. The drivers in Linux are kernel modules, most often in-tree
| - meaning that the source for the drivers is built along the
| rest of the kernel source code. Most hardware drivers depend on
| various common kernel structures that change often - when they
| do, the source for drivers is fixed practically in the same git
| branch. There is no driver ABI to speak of.
| pjmlp wrote:
| Besides all examples, Microsoft is now using TockOS for Pluton
| firmware, another Rust based OS.
|
| https://tockos.org/
| prmoustache wrote:
| > 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?
| wslh wrote:
| Is the "--privileged" option ironic here? The project is very
| interesting, but it feels a bit pedantic, especially when
| emphasizing Rust's safety features while downplaying Linux. At
| the same time, it seems they're not fully applying those
| principles themselves, which makes it feel like they're not
| quite 'eating their own lunch'.
| prmoustache wrote:
| A bit below in the github readme there is a link to the
| handbook where they explain how to build and run the project
| using cargo:
|
| https://asterinas.github.io/book/osdk/guide/run-project.html
| oefrha wrote:
| Hardly different from downloading random binary installers and
| executing them. Or random source distributions and (sudo) make
| install. Or npm/pip/cargo/etc. install random packages. Before
| anyone mentions distros and package managers, as a former team
| member of a major package manager I can assure you we don't vet
| shit beyond project notability, and new versions are accepted
| semi-automatically. We'll yank something after the fact if you
| report a malicious update, sure.
|
| curl | bash has an actual problem: potential execution of an
| incomplete script (which can be mitigated with function
| calling). And there's the mostly theoretical problem of the
| server being pwned / sending malicious code just to you (which
| of course also applies to any other unsigned channel).
| Arbitrary code execution is never a problem unique to it, but
| people dunk on it all the time because they saw another person
| dunking on it in the past.
| hnfong wrote:
| > as a former team member of a major package manager I can
| assure you we don't vet shit beyond project notability, and
| new versions are accepted semi-automatically
|
| An example that illustrates this:
| https://lwn.net/Articles/22991/
|
| (And wow, it's been 22 years already...?)
| sylware wrote:
| Linux is mostly a decades long maintained repository of real
| hardware programing code, and written in mostly simple "kernel"
| 'C', not some ultra complex syntax language (unfortunately, it
| has been tied to compiler specific extensions or "modern C"
| tantrums, _generic for instance).
|
| Have a look at AMD GPU driver. Massive, and full of
| 'stabilization/work around' code... happening all the time, for
| years.
|
| I guess, the real "first thing first" is to design hardware,
| performant hardware on latest silicon process , with a, as simple
| as possible, modern, standard and stable hardware programing
| interface. Because, for many types of hardware, 'now we know how
| to do it properly' (command hardware ring buffers usually, or a
| good compromise for modern CPU architecture, like RISC-V).
|
| Another angle of "cleanup", I guess it would be the removal of
| many of the C compiler extension (or "modern C") tantrums from
| linux, or at least proper alternatives with not-inline assembly
| to allow small and alternative compilers to step in.
|
| Personally, I tend to write rv64 assembly (which I interpret on
| x86_64), but for the userland. If I code C, I push towards mostly
| "simple and plain C99".
|
| The more I think about it, the more I get the following coming to
| my mind: 'hardware with simple standard interfaces' and standard
| assembly for the kernel.
| artemonster wrote:
| Huh? What is this nonsense?? Are you suggesting that you like
| to write practical-oriented, simple and working solutions
| instead of yak shaving half a day at perfecting ridiculous type
| signatures, removing ,,unsafe" code and satisfying borrow
| checker? Proposterous! /s
| a99c43f2d565504 wrote:
| Zig kernel when
| bigfishrunning wrote:
| When someone writes one
| rpgraham84 wrote:
| oh cool, now I can have an unverifiable kernel from a team in
| China
| delduca wrote:
| This is exactly what I was discussing with a friend who works on
| the kernel. I don't think Rust should be supported; the kernel
| should remain in C. Instead, a completely new kernel in Rust
| should be created with API/ABI compatibility with the original
| kernel.
___________________________________________________________________
(page generated 2024-10-16 23:01 UTC)