Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supporting Linux kernel development in Rust

lwn.net

Post reply on HN
Print view View original

261–270 of 365 posts

Re: Supporting Linux kernel development in Rust

#261

Post by adwn »

pjmlp wrote: post #242
_ph_ wrote: post #240

Earlier quoted context omitted.

But if they have IP considerations or trade secrets to protect, they wouldn't contribute them to any other open source project either. This way, they can at least upstream everything, which doesn't fall under these restrictions.

They don't upstream everything, while reducing their development costs, that is the point. Personally I don't care, but I bet many FOSS anti-GPL advocates will eventually care.

> They don't upstream everything, while reducing their development costs, that is the point.

_ph_ meant to write "This way, they can at least upstream everything which doesn't fall under these restrictions." (note the deleted comma before "which"), i.e., they can at least upstream something instead of nothing.

Re: Supporting Linux kernel development in Rust

#263

Post by cbmuser »

gok wrote: post #89
cbmuser wrote: post #80

If we get the Rust backend for gcc finalized and merged first, it would be much easier to get Rust code into the kernel: > https://github.com/philberty/gccrs/

That's a front end?

You’re right, sorry. I’ve been dealing too much with backends that my brain mixed up the words.

Re: Supporting Linux kernel development in Rust

#265

Post by hyperman1 »

captn3m0 wrote: post #42
est31 wrote: post #17

Earlier quoted context omitted.

Wait till we tell them that Linux is a trademark of Linus Torvalds.

it involves the "patches-must-be-approved-by-upstream" to still be called Rust clause that Rust inherits from the Mozilla Trademark policy. Its the same policy that led to the creation of IceWeasel/Waterfox etc.

Here is the core of the issue:

https://lwn.net/Articles/118279/

Debian wanted to allow anyone to patch their firefox. Mozilla said OK, but not with our name attached to it.

And this makes sense on some level : No project wants to provide support for someone else's bugs.

Re: Supporting Linux kernel development in Rust

#266

Post by mac01021 »

dnautics wrote: post #139
jasonhansel wrote: post #137

I'm concerned about the gradual move from GCC to LLVM. The lack of copyleft protections on LLVM means that it's much more dependent on corporate sponsorship, and means that there's a risk that major improvements to LLVM compilers will only become available as proprietary products. People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.

Can you give an example of a non-copyleft open source product where the major improvement is proprietary?

BSD -> Mac OS?

Re: Supporting Linux kernel development in Rust

#267

Post by _ph_ »

adwn wrote: post #261
pjmlp wrote: post #242

Earlier quoted context omitted.

They don't upstream everything, while reducing their development costs, that is the point. Personally I don't care, but I bet many FOSS anti-GPL advocates will eventually care.

> They don't upstream everything, while reducing their development costs, that is the point. _ph_ meant to write "This way, they can at least upstream everything which doesn't fall under these restrictions." (note the deleted comma before "which"), i.e., they can at least upstream something instead of nothing .

Yes, thanks :)

Re: Supporting Linux kernel development in Rust

#268

Post by pjmlp »

zelly wrote: post #224
fractalb wrote: post #203

Earlier quoted context omitted.

What if those bigcorps don't merge some improvements for getting an edge over the competitors? And, what if every one of those bigcorps do the same? How would that impact the project in the future?

Already the case for Apple LLVM which has optimizations for Apple Silicon not upstreamed and never will be upstreamed.

And watchOS, its bitcode is more portable than regular LLVM bitcode.

Re: Supporting Linux kernel development in Rust

#269

Post by pjmlp »

why_only_15 wrote: post #219
nielsbot wrote: post #204

Sounds like they have the same problem Apple's Swift does for calling into C/Obj-C. Two examples: My understanding is that there's a ton of code and added complexity in Swift itself to support Obj-C interoperation. And while you can call C and Obj-C APIs, as-is, there was/is basically a company-wide effort to write API wrappers (aka. overlays) for existing system APIs. For the second part, maybe if Rust for Linux ker…

This is mostly just a random tidbit but one of the fascinating things to me about Swift ObjC interop is that it's not just that Swift was modified for ObjC, but ObjC was modified for Swift as well. In general it works pretty well and I wonder how much of that is because Apple can modify ObjC whenever it wants.

.NET C++/COM also went through a similar process.

Re: Supporting Linux kernel development in Rust

#270

Post by pjmlp »

geofft wrote: post #116
ogoffart wrote: post #91

> The ubiquitous kmalloc() function, for instance, is defined as __always_inline, meaning that it is inlined into all of its callers and no kmalloc() symbol exists in the kernel symbol table for Rust to link against. This problem can be easily worked around — one can define a kmalloc_for_rust() symbol containing an un-inlined version but performing these workarounds by hand would result in a large amount of manual wo…

Yup - that got a very brief mention in the article as "Google is working on automated C++ conversions"; there's also https://github.com/google/autocxx which builds on top of it. C++ is a richer language than C and has more information about ownership (e.g., if you return a std::string you know how ownership works; if you have two arguments that are a char * and a length it's much less clear), but additional annotatio…

That is one of the learnings Microsoft had with XP SP2, hence SAL macros everywhere on Windows APIs.
Post reply on HN