Initial Rust DRM Abstractions, AGX Apple DRM Driver Posted For Review

[oiaohm]

You're missing the point. My example was that in many cases you don't even have to modify the source header.

But the example project you picked was not one of them. Need to pick you example a little more carefully.

Obviously, modifying the header should be done in some cases. In Rust, you can't even use C headers in the first place, you have to write your own compatible one with compatible interface. Heck you even have "asm" name for functions (GCC extension) in worst situation with symbol, if you can't use the linker to change it.

This is not correct.

https://github.com/rust-lang/rust-bindgen

bindgen task C/C++ header in one side and spits a rust compatible interface out the other. With how complex processing C/C++ headers are C and C++ compliers in lot of project use precompiled headers so need to run a convert here I don't see as problem.
Rust language lacks means at this stage to do

extern "C" {
   include "someheader.h"
}

But is this a big deal

https://docs.rust-embedded.org/book/interoperability/c-with-rust.html

The section "Automatically generating the interface" yes bindings.rs option there is basically the precompiled header route so not having to process the C headers over and over converting them to rust slowing down build times.

Rust directly using C and C++ header files is most likely bad. Indirectly does exist without lots of developer work as long as you don't care about the interfaces being unsafe.

The point is that C++ can interface with C perfectly and I challenge you to give me an example where it can't. The reverse is also true, C can also interface with C++, even if it's a bit painful with C++ libraries, but it can. Yes, you might have to write your own header in C++, so? It's still much easier than Rust and Rust CANNOT do some of it without "unsafe", which rustaceans have a phobia of.

You asked for example when your wlroots example already had a case where C++ and C could not interface perfectly.

Unsafe point issue I don't disagree with is a issue but you get something key wrong. bindgen the least work way of interfacing with C does not have means of generating a safe interfaces. If you mess around setting of bindgen options you can get it to spit out safe rust interfaces at times. Yes bindgen lacks the smarts to know hey I just processed X header file all the operations are safe so I should declare it safe yes lacks the means to declare the information in the C/C++ header file.

/** <div rustbindgen mustusetype></div> */

You can put rustbindgen directions into your C and C++ header files. But these have to be put in the correct locations.
Like the command line for that is "--must-use-type <regex>"

You cannot create a wrapper.h and put all the commandline options you would pass into bindgen into it. This is a weakness of the current bindgen. Either you end up with a commandline from hell or having todo a lot of header file modifications this is more a implementation limitation of bindgen than a design defect.

Bindgen at this stage still does not contain enough options and processing intelligence to make safe interfaces as much as you would like.

Weasel my point of view is rusts interface generation from C, C++ and Object C need work. The bindgen bit need to be improved to the point where it can be giving the directives to spit out safe rust interfaces from C/C++/object C header files lot more often with less work.

Yes safe rust interfaces being able to be spat out with upstream support that could end in needing C/C++/object C header files need to contain a little extra information like C headers do so C++ use them without issue most of the time. Of course we need bindgen to be able to process that extra information and make safe interfaces.

[smitty3268]

Rust CANNOT do some of it without "unsafe", which rustaceans have a phobia of.

Doing it with unsafe is the equivalent of doing it in c++, so i'm not sure why you think it's worse. Just because Rust developers would prefer to have something that is provably safe doesn't make that a language flaw, just a developer preference.

From what I've seen, the biggest annoyance in the kernel rust code so far is the inlined C code that has to be exported as a function call so that rust can see it. Probably not great for performance. Also I think there's an issue with using C macros in certain cases, in which case the code has to be duplicated in rust.

[Barnacle]

C++ was clearly created by people who did not properly understand the strengths and virtues of C before they tried to "improve" it. Rust was clearly created by a bunch of Silicon Valley wokesters who are obsessed with "progress", where "progress" is defined as rejecting anything that is old without understanding the first thing about it and why it was successful in the first place.

[Weasel]

But the example project you picked was not one of them. Need to pick you example a little more carefully.


This is not correct.

https://github.com/rust-lang/rust-bindgen

bindgen task C/C++ header in one side and spits a rust compatible interface out the other. With how complex processing C/C++ headers are C and C++ compliers in lot of project use precompiled headers so need to run a convert here I don't see as problem.
Rust language lacks means at this stage to do

extern "C" {
include "someheader.h"
}

But is this a big deal

https://docs.rust-embedded.org/book/interoperability/c-with-rust.html

The section "Automatically generating the interface" yes bindings.rs option there is basically the precompiled header route so not having to process the C headers over and over converting them to rust slowing down build times.

Rust directly using C and C++ header files is most likely bad. Indirectly does exist without lots of developer work as long as you don't care about the interfaces being unsafe.

Who said it has to use C/C++ headers directly??! Dude wtf are you even arguing about? All I said is that sometimes Rust cannot interact with a C API, I don't care how you write the headers or the interface, it just can't, without "unsafe".

You asked for example when your wlroots example already had a case where C++ and C could not interface perfectly.

Where? All I saw was that the guy was saying how easy it is in C++, which is the complete opposite of what you think. Here:

To do all of this, and then go write Way Cooler, already a big undertaking, is too much for me to commit to. When the benefit at the end of the day is just so I don’t have to write C, that doesn’t really make it worth it. If I got this out of the box by simply linking to the library, like I can in C++, then it would be much more tenable.

Emphasis added.

So still waiting for that example.

[oiaohm]

Who said it has to use C/C++ headers directly??! Dude wtf are you even arguing about? All I said is that sometimes Rust cannot interact with a C API, I don't care how you write the headers or the interface, it just can't, without "unsafe".

The source you used then you nicely went and highlighted it "like I can in C++". So that source of yours said a little more than what you thought it did. So I take by this response you did not mean must allow headers directly and you missed that what you had referenced had that in it.

Need to read the issue I quoted back in response to notice how you had to use wlroots

extern "C" {
include "someheaders.h"
}

This is exactly how you have to use wlroots under C++. As well as include some macros to define some things out of existence and macro replace others.

Almost everything I see needing done to bindgen you need todo to have wlroots work with C++.

Where? All I saw was that the guy was saying how easy it is in C++, which is the complete opposite of what you think. Here:Emphasis added.

So still waiting for that example.

https://github.com/swaywm/wlroots/issues/682

This is issue on wlroots I quoted before and it not the only issue opened over C++. Turns out wlroots not very nice with C++ either. The C++ issues with wlroots end up getting closed with some workaround being put in the issues all the time with no wlroots code fixes. Yes fun of finding all the closed issues to find all the fixes so C++ program using wlroots works. wlroots is one of those items that is not C++ friendly.

[Ironmask]

C++ was clearly created by people who did not properly understand the strengths and virtues of C before they tried to "improve" it. Rust was clearly created by a bunch of Silicon Valley wokesters who are obsessed with "progress", where "progress" is defined as rejecting anything that is old without understanding the first thing about it and why it was successful in the first place.

And you don't even know who made Rust or why.
Why did you write such a painfully ironic post? This is like watching someone slip on a banana peel they just dropped on the ground.

[Weasel]

https://github.com/swaywm/wlroots/issues/682

This is issue on wlroots I quoted before and it not the only issue opened over C++. Turns out wlroots not very nice with C++ either. The C++ issues with wlroots end up getting closed with some workaround being put in the issues all the time with no wlroots code fixes. Yes fun of finding all the closed issues to find all the fixes so C++ program using wlroots works. wlroots is one of those items that is not C++ friendly.

How is that an example of anything? You literally proved my point how easy it is to interface C++ with C. In your example you don't even have to modify the original header.

What are you even arguing for? You claimed C++ can not interface with all C APIs, even by rewriting headers. I'm still waiting for an example where you can't use a C API from C++, even with your own rewritten header (in C++). You claimed it, so prove it.

[oiaohm]

How is that an example of anything? You literally proved my point how easy it is to interface C++ with C. In your example you don't even have to modify the original header.

What are you even arguing for? You claimed C++ can not interface with all C APIs, even by rewriting headers. I'm still waiting for an example where you can't use a C API from C++, even with your own rewritten header (in C++). You claimed it, so prove it.

I should not need to explain this one. Why should you not mix C++ run-times we have done this one before because of memory management right weasel. As you said the last time if you are careful you can mix incompatible C++ runtime and not cause too much hell.

https://gcc.gnu.org/legacy-ml/gcc-help/2002-04/msg00229.html

Its not a new form of O my hell. C and C++ don't in fact allocate memory the same way. It is possible for a person coding in C todo memory allocations in a C++ incompatible way. Yes perfectly valid to standard C. Rewriting the header not going to help you this is core code of library problem.

This is not the only known Pandora box. The fact something is being developed and only tested upstream as C means they are not testing for any of the cases where C is C++ incompatible.

Weasel common belief that you can safely mix C and C++ all the time is not in fact true and has not been for decades. Lot of cases people don't use the edge cases or know they exist.

[Barnacle]

And you don't even know who made Rust or why.
Why did you write such a painfully ironic post? This is like watching someone slip on a banana peel they just dropped on the ground.

Yeah, still waiting for somebody to write an application that proves the superiority of Rust. Maybe less time trolling the internet and more time proving how awesome Rust is?

[oiaohm]

Yeah, still waiting for somebody to write an application that proves the superiority of Rust. Maybe less time trolling the internet and more time proving how awesome Rust is?

https://wiki.osdev.org/Rust

Rust has already done the small hobby OS stage. This has shown superiority to all the normal and abnormal program language choices for making OS in.

If you are asking the question what is the program language that will take the least amount of time to write a stable OS from scratch with our current list of program language the answer is rust. This is proven out by the OS that have been written in rust and how little time they in fact have taken to get to particular stages.

Please note I am not saying rust is all good. Rust integrate into existing OS based on C or C++ not as simple as one would hope for. Rust limited compiler support is another big problem that is starting to be addressed.

You asked for application people have written OSs. This kind of explains Linux kernel interest in rust.