Announcement

Collapse
No announcement yet.

Linux's VGEM Kernel Driver Being Rewritten In Rust

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • darkonix
    replied
    Originally posted by kpedersen View Post

    Arguably a compiler is one thing that Rust *should* be able to do without pulling in a bunch of C binding layers from crates.io.

    After all, a compiler has very simple IO. It takes plain text files and emits binary files. It shouldn't depend on any of the underlying operating system (where Rust is fairly weak at interfacing against).

    If you can do it in Javascript, you can probably just about do it with Rust.
    That's only valid for small compilers. You can write those in most languages in a relatively simple way. As you add more complexity it make more sense to reuse code. C has a culture of not reusing external libraries because of historical & technical reasons. Modern languages don't have the same culture so they encourage reuse more and make it easy to do so.

    Leave a comment:


  • sinepgib
    replied
    Originally posted by Jabberwocky View Post
    Are there any ARM-based Apple laptops that have working input, display, graphics, power management in Linux?
    All of them AFAIK. Asahi gives a good OOB experience. Maybe power management is not supported, and while graphics are supported accelerated graphics are still WIP. Very off-topic question though.

    Leave a comment:


  • sinepgib
    replied
    Originally posted by CommunityMember View Post
    They may have a call, but if they unreasonably restrict rust due to philosophical reasons they may find that others may end up being the subsystem maintainers.
    There are logical reasons to restrict Rust though. As with pretty much everything in engineering, there is a tradeoff and different programmers will tilt toward different decisions. For example, lifespan is a reasonable argument: compared to C, Rust is young, which means C is a (slightly, IMO) better bet for expecting it to be around in 20-30 years from now, simply because it already lived such long times.

    Originally posted by CommunityMember View Post
    ​Some parts of the kernel will always be so low level architecture specific that assembly may be the best approach, but if the code is trivial, migrating to rust may be low hanging fruit that may be chosen precisely because it is trivial (starting simple is commonly considered a good approach (was not almost everyone's first C program "Hello World"?)).
    Yeah, I don't know how I missed this part really, as it is the most obvious one. But the parts that absolutely need assembly language tend to be few and small and are already not C (I mostly assume we only mean to rewrite the C parts, I may be wrong). Some will also be kept as assembly for performance, the sufficiently smart compiler that vectorizes complicated algorithms isn't yet here AFAIK.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by Developer12 View Post

    If you want really crazy, legend has it there's an effort to write a new C compiler and toolchain entirely in rust. How the tables turn.
    No such effort exists of course. a) mrustc (entirely in C++) and GCC RS (reusing Rust libraries outside of the compiler) are written in C++ as I have noted earlier in the thread b) Even if there was an effort, C is a pretty common language to write compilers. Google's Go compiler itself was originally written in C and Python's reference compiler, CPython continues to be written in C today as the name indicates although alternatives like pypy are self hosting.

    Leave a comment:


  • kpedersen
    replied
    Originally posted by Developer12 View Post

    If you want really crazy, legend has it there's an effort to write a new C compiler and toolchain entirely in rust. How the tables turn.
    Arguably a compiler is one thing that Rust *should* be able to do without pulling in a bunch of C binding layers from crates.io.

    After all, a compiler has very simple IO. It takes plain text files and emits binary files. It shouldn't depend on any of the underlying operating system (where Rust is fairly weak at interfacing against).

    If you can do it in Javascript, you can probably just about do it with Rust.

    Leave a comment:


  • aht0
    replied
    Originally posted by sinepgib View Post

    I see several ways it could end up in an incomplete migration:
    - Friction with some more reluctant developers (not everyone is on board with Rust AFAIK), some of whom may be maintainers (so they have a call about whether or not Rust makes it into their subsystem).
    - Some parts are simply not worth the extra effort, say, several architectures and drivers have had only minor bug fixes and corrections to fit interface changes for years. I don't think they will drop them only to avoid migrating them to Rust, as long as they don't get in the way of migrating the rest.
    - Some parts may either be deemed too sensitive for a rewrite or it may simply not be that beneficial for that case to migrate to Rust (say, trivial code that you can really be sure has no memory safety/UB bugs).

    I think stuff will be migrated on an as-needed (particularly buggy areas) and/or opportunistic (no need to keep doing new development in C) basis, rather than just go all in.
    Agreed. More likely to happen in DragonFly, less devs (seen about 10 commiting/fixing bugs), less possible friction. But they also seem fixed on C.
    John Marino's Synth (written in Ada) was re-impemented into DragonFly as an OS's integral utility in C. Still kinda buggy and some features missing :/
    ​​​​​​
    Seeing Linux rn more forward-thinking..
    Last edited by aht0; 02 March 2023, 05:04 AM.

    Leave a comment:


  • Jabberwocky
    replied
    Are there any ARM-based Apple laptops that have working input, display, graphics, power management in Linux?

    Leave a comment:


  • Developer12
    replied
    Originally posted by RahulSundaram View Post

    Not really. It is a fairly common step in a language to write the compiler in the language itself after a point. Go did this a few years back for example.
    If you want really crazy, legend has it there's an effort to write a new C compiler and toolchain entirely in rust. How the tables turn.

    Leave a comment:


  • lowflyer
    replied
    Can somebody please clean-up the rusty corners of the kernel?

    Leave a comment:


  • CommunityMember
    replied
    Originally posted by sinepgib View Post

    I see several ways it could end up in an incomplete migration
    I doubt there will ever be a 100% migration, but where appropriate, and resources are available, it might slowly happen...

    - Friction with some more reluctant developers (not everyone is on board with Rust AFAIK), some of whom may be maintainers (so they have a call about whether or not Rust makes it into their subsystem).
    They may have a call, but if they unreasonably restrict rust due to philosophical reasons they may find that others may end up being the subsystem maintainers.

    - Some parts are simply not worth the extra effort, say, several architectures and drivers have had only minor bug fixes and corrections to fit interface changes for years. I don't think they will drop them only to avoid migrating them to Rust, as long as they don't get in the way of migrating the rest.
    Rewriting just for the sake of rewriting into a different language is rarely justified. Many (older) ERP systems still have their existing COBOL code for which there is no reason to change, as it only has costs to do the work and to reverify the results. That does not mean that that COBOL code may not eventually get replaced, but it is rarely a priority as long as it just works as it always has.

    - Some parts may either be deemed too sensitive for a rewrite or it may simply not be that beneficial for that case to migrate to Rust (say, trivial code that you can really be sure has no memory safety/UB bugs).
    Some parts of the kernel will always be so low level architecture specific that assembly may be the best approach, but if the code is trivial, migrating to rust may be low hanging fruit that may be chosen precisely because it is trivial (starting simple is commonly considered a good approach (was not almost everyone's first C program "Hello World"?)).

    Leave a comment:

Working...
X