Rust in the FreeBSD kernel

msplsh said:
IDK, seems like they solved that problem
Click to expand...
Sadly not. Bindings generators (including SWIG that came before it) can't quite do the full job. Thats why you have many, many bindings in crates.io such as for SDL2.

You have the *-sys crates which are the thin unsafe bindings (some partially generated), and then you have the idiomatic Rust bindings sat ontop of those unsafe bindings which present a more Rust-like API.

Referring back to that paper I linked previously, it discusses one of the key benefits of C++ is that "C++ to C interoperability does not require any interface definition language (IDL) [12], as C++ understands C definitions due to their similar syntax. This is not the case for arbitrary 𝐿1 to 𝐿2"

The only high level language I have seen that does allow direct interop with C, is basically C++ and Obj-C. Actually one of Stroustrups key design decisions or C++ to be successful was because he understood that interop with C was so important. I imagine that had this not been the case, the language would have failed to receive adoption by the industry.

msplsh said:
Why would... someone build something that takes so long to make and then peace out and not maintain it?
Click to expand...
They move on to other projects? They get busy with work? They have a kid? So many reasons. Its so common that tools such as cargo-unmaintained have been developed.

msplsh said:
You also can't force people to write drivers in C either, so GLHF?
Click to expand...
Since the API is only accessibly by C, they can *only* write their drivers in C currently. This is why the Rust community has been trying to implement Rust hardware abstraction bindings in Linux for over two years now.
 
kpedersen said:
The only high level language I have seen that does allow direct interop with C, is basically C++ and Obj-C. Actually one of Stroustrups key design decisions or C++ to be successful was because he understood that interop with C was so important. I imagine that had this not been the case, the language would have failed to receive adoption by the industry.
Click to expand...

The Common Lisp compiler Clasp interfaces to C and some C++ by using the LLVM and Clang libraries, aka it properly parses the header files and gets structs and function signatures out of that. In other words, it drags most of a compiler around.

github.com

GitHub - clasp-developers/clasp: clasp Common Lisp environment

clasp Common Lisp environment. Contribute to clasp-developers/clasp development by creating an account on GitHub.
github.com github.com
 
cracauer@ said:
The Common Lisp compiler Clasp interfaces to C and some C++ by using the LLVM and Clang libraries, aka it properly parses the header files and gets structs and function signatures out of that. In other words, it drags most of a compiler around.

https://github.com/clasp-developers/clasp
Click to expand...
I do like the "bolt on a basic C frontend" idea. It was my option 1 because it would be easier than writing an entire OS.

It seems heavy but I honestly think that would be a good approach for Rust. Especially since it is already built on LLVM, then parts of Clang almost comes for free. The successor would be called Crust.
 
kpedersen said:
Sadly not
Click to expand...
Literally what the Linux Rust developers say they use. But you say it "doesn't work", so I suppose it's a real head-scratcher as to who to believe.

All your examples are cargo related, but nobody's talking about third parties, just core devs. Nobody is using SDL2 in the Kernel.

It's farcical that a "finding" of that paper is that C++ interops well with C. Of course? Same goes with Objective-C. Both literally bootstrapped off of C! This is the failure of imagination: That nothing can be better than C if it's not C-based.

kpedersen said:
they can *only* write their drivers in C currently
Click to expand...
Kind of the point, prove it works well enough compared to everything else.
 
msplsh said:
Literally what the Linux Rust developers say they use. But you say it "doesn't work", so I suppose it's a real head-scratcher as to who to believe.
Click to expand...
If you see the amount of work, the Rust community has put into their Rust abstractions binding layer, it is probably safe to assume bindgen has not been successful at automating the task of generating bindings. As I mentioned before, they have been working on this for years now. So its not much of a puzzle as to what to believe.

msplsh said:
All your examples are cargo related, but nobody's talking about third parties, just core devs. Nobody is using SDL2 in the Kernel.
Click to expand...
I'm talking about both kernel land *and* userland. The binding problem is present in both environments. SDL2 is just a nice clean encapsulated example to demonstrate a small library which bindgen can still not quite entirely automate. If you want to see an example of manual binding efforts in the Linux kernel; there are plenty of examples.

msplsh said:
It's farcical that a "finding" of that paper is that C++ interops well with C. Of course? Same goes with Objective-C. Both literally bootstrapped off of C!
Click to expand...
Bingo! Hence my earlier recommendation of bolting on a C frontend onto Rust. Evolution rather than revolution is likely to be the only solution at this stage in the game. Which is why Rust is struggling to gain a foothold. People can have an imagination and make up fantasies until the cows come home but they need to be pragmatic if they want to get any work done.

msplsh said:
This is the failure of imagination: That nothing can be better than C if it's not C-based.
Click to expand...
Now for the crazy bit. For almost any programming language to communicate. I.e:
  • Rust <-> Java
  • Python <-> Java
  • .NET <-> Java
They can't do it. They *have* to go through C.
  • Rust <-> C via FFI-JNI <-> Java
  • Python <-> C via FFI-JNI <-> Java
  • .NET <-> C via Pinvoke-JNI <-> Java
So really, don't think of C as a language at this point. Think of it as the entire computing platform. So naturally C-based languages will have a massive advantage.
 
msplsh said:
They don't want open drivers and nobody cares about their opinion on that.
Click to expand...

That's objectively false.

And it's not a matter of opinion. The question posed was to determine if GPU vendors willing to rewrite their entire stacks in Rust. Which I highly doubt. Should the Linux kernel devs try to shoehorn Rust into an existing C world for GPUs; they'll just move onto the next (and possibly better) C/C++ based alternative.
 
kpedersen said:
Now for the crazy bit. For almost any programming language to communicate. I.e:
  • Rust <-> Java
  • Python <-> Java
  • .NET <-> Java
They can't do it. They *have* to go through C.
  • Rust <-> C/FFI <-> Java
  • Python <-> C/FFI-JNI <-> Java
  • .NET <-> C/Pinvoke-JNI <-> Java
So really, don't think of C as a language at this point. Think of it as the entire computing platform. So naturally C-based languages will have a massive advantage.
Click to expand...

I was working for a long time on a project that was in Common Lisp, with a C++ library. We didn't use Clasp but SBCL, so every C++ thing available to Lisp had to go through a pure C interface. Major pain, you first have to wrap all classes and their methods in C, and then do the "normal" C to Lisp FFI. But I do have to say it was still worth it.

Objective-C can reasonably be FFIed without a C layer, you just use your knowledge of name mangling to get your claws on the symbols.

Things get really interesting if you want to be able to call in both directions an pass function pointers of the other language around and want to use them as higher order functions.
 
Beastie7 said:
That's objectively false.

And it's not a matter of opinion. The question posed was to determine if GPU vendors willing to rewrite their entire stacks in Rust. Which I highly doubt. Should the Linux kernel devs try to shoehorn Rust into an existing C world for GPUs; they'll just move onto the next (and possibly better) C/C++ based alternative.
Click to expand...

Tha AMD GPU drivers in the Linux kernel consist to a major part of automatically generated C files, presumably directlt out of the chip design software. Might not be that diffcult to change the output language.
 
kpedersen said:
The only high level language I have seen that does allow direct interop with C, is basically C++ and Obj-C.
Click to expand...
So does the V language. Example:

//C function declaration in V
fn C.select(ndfs int, readfds &C.fd_set, writefds &C.fd_set, exceptfds &C.fd_set, timeout &C.timeval) int
....
res := C.select(fd + 1, &read_set, C.NULL, C.NULL, &ts)
 
I know it's difficult and someone have strong objection to it, but I believe only good solution would be to "compile into C, with inline asm for language-specific implicit parameters (including additional dedicated ELF section) handling. This way, theoretically, no binding-with-C issues can happen.
 
V at present translate to C and uses a C compiler as its own native codegen is not quite ready for prime time. But it is not necessary to always compile to C as long as the foreign function interface rules are well defined and close to C. Rust can likely also interoperate with C.

But clearly using a different (higher level) language along with C for kernel work has its own set of non-trivial issues, whether Rust or some other language (let's call it !C). If the interface to some C function changes and that breaks code in !C, does the C programmer also have to know !C? Or will they have to work with a !C expert? Or will the change won't be accepted? And it is worse for FreeBSD since given its limited resources it ends up borrowing code from Linux and what happens if some of it is written in !C?
 
T-Aoki said:
I know it's difficult and someone have strong objection to it, but I believe only good solution would be to "compile into C, with inline asm for language-specific implicit parameters (including additional dedicated ELF section) handling. This way, theoretically, no binding-with-C issues can happen.
Click to expand...

With the supposed purpose of Rust people keep regurgitating; Capsicum/CHERI has already addressed these issues years ago. They simply could've taken the code and made use of it; instead of rewriting entire software ecosystems that work. Pure NIH circus behavior. I don't see why Rust exists outside of these problem cases.
 
kpedersen said:
Now for the crazy bit. For almost any programming language to communicate. I.e:
  • Rust <-> Java
  • Python <-> Java
  • .NET <-> Java
They can't do it. They *have* to go through C.
  • Rust <-> C via FFI-JNI <-> Java
  • Python <-> C via FFI-JNI <-> Java
  • .NET <-> C via Pinvoke-JNI <-> Java
So really, don't think of C as a language at this point. Think of it as the entire computing platform. So naturally C-based languages will have a massive advantage.
Click to expand...
It can get sillier. A long time ago I worked on software that had initially been developed for NextOS on Next boxes. That was a really elegant early object-oriented platform. Unfortunately, the writing had been on the wall for Next before I came along. New CTO was hired and decided (correctly) that a port to Windows was necessary, and (incorrectly) that the GUI front end for that port would be Visual Basic. Now the VB of the time knew nothing about objects, so a C layer was needed to interop with the C++ back-end. At this point we have have C++ -> C -> VB.

Lo and behold, it turns out VB at the time (and possibly still now) was an absolute crap platform. Some motivated engineers started re-writing the GUI using MFC (Microsoft Foundation Classes) behind the CTO's back. It was a masterful play, as they were ready with an alternative when the VB abomination predictably failed. But because the project was written on the sly and in a rush, there was no time to factor out the C layer. You guessed it, the final stack was C++ -> C -> C++.
 
Beastie7 said:
With the supposed purpose of Rust people keep regurgitating; Capsicum/CHERI has already addressed these issues years ago. They simply could've taken the code and made use of it; instead of rewriting entire software ecosystems that work. Pure NIH circus behavior. I don't see why Rust exists outside of these problem cases.
Click to expand...
The circus behavior is this entire argument. These are completely different things: one of them is a language with a strong type system (which selling point is not memory safety, but rather lifetime and mutability tracking) and another is a tagged pointer CPU arch extension. The latter helps to reliably crash misbehaving programs preventing bugs from becoming exploitable security issues (consider it a very cheap runtime sanitizer), while the former is aimed at catching bugs at the compiler level, allowing the programmer to spend less time with a debugger.

And if you are thinking that tagged pointers do not require any C code to be rewritten you are likely going to be disappointed.
 
bakul said:
So does the V language. Example:

//C function declaration in V
fn C.select(ndfs int, readfds &C.fd_set, writefds &C.fd_set, exceptfds &C.fd_set, timeout &C.timeval) int
....
res := C.select(fd + 1, &read_set, C.NULL, C.NULL, &ts)
Click to expand...
It does actually look close on first look but alas, these are just bindings. This example is basically just manually creating a V binding against the C select(2) function.

Via the V docs:

To overcome that limitation (that V does not have a C parser), V needs you toredeclare the C functions and structs, on the V side, in your .c.v files.Note that such redeclarations only need to have enough details about thefunctions/structs that you want to use.Note also that they do not have to be complete, unlike the ones in the .h files.
Click to expand...

But, it does look like it is a future goal of vlang to implement a C frontend.
 
You must log in or register to reply here.
Back
Top