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

The Linux Kernel Prepares for Rust 1.77 Upgrade

phoronix.com

Post reply on HN
Print view View original

71–80 of 107 posts

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#71

Post by Kamq »

habibur wrote: post #61
Narishma wrote: post #33

Earlier quoted context omitted.

But C doesn't statically link the standard library by default like Rust does.

Hello world deps for C : linux-vdso.so.1 (0x00007fff25cb8000) libc.so.6 => /lib64/libc.so.6 (0x00007fe5f08d9000) /lib64/ld-linux-x86-64.so.2 (0x00007fe5f0ae2000) And for Rust linux-vdso.so.1 (0x00007ffc109f9000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8eda404000) libc.so.6 => /lib64/libc.so.6 (0x00007f8eda222000) /lib64/ld-linux-x86-64.so.2 (0x00007f8eda4a8000) Rather Rust has 1 more dynamically linked library…

You missed the word "statically" in the post you commented on.

Dynamically linked libs rarely contribute heavily to binary bloat

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#73

Post by charcircuit »

rekado wrote: post #47
horeszko wrote: post #9

Earlier quoted context omitted.

LFS is Linux from Scratch right? ( https://www.linuxfromscratch.org/index.html ) What are the implications of using Rust on building Linux?

The Rust bootstrapping story is ugly. https://guix.gnu.org/blog/2018/bootstrapping-rust/

LFS does not need to do all of that. LFS already uses the host computer's C compiler, so it seems just as reasonable to also use the host computer's rust compiler.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#74

Post by charcircuit »

saghm wrote: post #55
bonzini wrote: post #40

Earlier quoted context omitted.

The alternative was to do the same and also not merge what they had. Stuff like custom allocator support is not optional.

I was confused when reading this because I was pretty sure that using other allocators had been supported for a while in Rust. From refreshing myself on the details, it seems that replacing the default allocator is stable ( https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html ), but the API for arbitrary allocators (which includes stuff like being able to do "zero-size" allocations) is not yet stable ( https://…

More importantly allocator_api adds try_new which means you can handle allocation errors.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#75

Post by remexre »

saghm wrote: post #55
bonzini wrote: post #40

Earlier quoted context omitted.

The alternative was to do the same and also not merge what they had. Stuff like custom allocator support is not optional.

I was confused when reading this because I was pretty sure that using other allocators had been supported for a while in Rust. From refreshing myself on the details, it seems that replacing the default allocator is stable ( https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html ), but the API for arbitrary allocators (which includes stuff like being able to do "zero-size" allocations) is not yet stable ( https://…

There's also https://docs.rs/allocator-api2/latest/allocator_api2/ -- I end up using this more often than I end up using custom allocators, simply because it has a stable version of the currently-unstable functions for constructing uninitialized Vec>s.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#76

Post by wongarsu »

ericbarrett wrote: post #70
bluejekyll wrote: post #17

Earlier quoted context omitted.

This is a good guide on building small Rust binaries: https://github.com/johnthagen/min-sized-rust This talks about going to extreme lengths on making the smallest Rust binary possible, 400 bytes when it was written, https://darkcoding.net/software/a-very-small-rust-binary-ind... The thing is, you lose a lot of nice features when you do this, like panic unwinding, debug symbols, stdlib… for kernel and some embedded d…

> debug symbols In ye olden days it was common to distribute a binary without debug symbols, but to keep a copy of them for every released build¹. If an application crashed (panicked, signalled, etc.) you got a core dump that you could debug using the stripped binary together with the symbol file. This gave you both smaller binary sizes and full debugging capability at the cost of some extra administration. I'm not s…

It's possible, but rust follows platform conventions in only doing this by default on Windows. However it is now easy to configure by setting split-debuginfo in your Cargo.toml [1]

1: https://doc.rust-lang.org/cargo/reference/profiles.html#spli...

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#77

Post by cout »

forrestthewoods wrote: post #69
kramerger wrote: post #4

The LKM post mentions binary size improvements. One issues I have had with Rust applications is the huge binary size (yes, I know this has improved a bit lately). Is there a good comparison between kernel C and kernel Rust code in this regard?

> is the huge binary size Can you quantify this? How big is too big? Ideally for a real program, and not an experiment to make the tiniest possible program. On my Windows machine ripgrep rg.exe is just 4.2mb. Making that smaller feels irrelevant. I’m not convinced that binary size is a real problem. But I’m open to evidence!

It would be nice if it fit on a standard size 1.44MB floppy, but given that I haven't used a floppy drive in about a decade, yeah I guess it doesn't matter much.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#78

Post by bpye »

pornel wrote: post #36
nequo wrote: post #32

Earlier quoted context omitted.

Due to dead code elimination, the compiler already omits all of that part of stdlib that your code doesn’t use.

Not quite. Every Rust program will have some code path that may panic, and the default panic handler uses debug formatting, which uses dynamic dispatch, which prevents elimination of the rest of the printing machinery. There’s panic_immediate_abort unstable setting that makes Rust panics crash as hard as a C segfault, and only then you can get rid of a good chunk of stdlib.

The printing machinery is quite unfortunate. Beyond being large, dynamic dispatch makes any attempt at stack size analysis much harder.

I’ve used Rust for some embedded side projects and I really wish there was a way to just get some unique identifier that I could translate (using debug symbols) to a filename and line number for a crash. This would sort of be possible if you could get the compiler to put the filenames in a different binary section, as you could then just save the address of the string and strip out the actual strings - but today that’s not possible.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#79

Post by bscphil »

surajrmal wrote: post #14
zadokshi wrote: post #10

Earlier quoted context omitted.

Saying part of the problem is “using too many dependencies” is not an overly helpful thing if the ecosystem keeps on trying to download 3Gb of build dependencies because you tried to use some simple little library. The problem is obvious, it’s the solution that is much more difficult.

It's not a problem when you compare it to C. You have few available dependencies to choose from with C. If you are equally picky and constrain yourself to parts of the ecosystem which care about binary size, you still have more options and can avoid size issues. For things like a kernel, it is moot as most deps are simply not possible to use anyway. When you consider the full ecosystem, you need to really compare it…

> If you are equally picky and constrain yourself to parts of the ecosystem which care about binary size, you still have more options and can avoid size issues.

What's an example of this for, say, libcurl? On my system it has a tiny number of recursive dependencies, around a dozen. [0] Furthermore if I want to write a C program that uses libcurl I have to download zero bytes of data ... because it's a shared library that is already installed on my system, since so many programs already use it.

I don't really know the appropriate comparison for Rust. reqwest seems roughly comparable, but it's an HTTP client library, and not a general purpose network client like curl. Obviously curl can do a lot more. Even the list of direct dependencies for reqwest is quite long [1], and it's built on top of another http library [2] that has its own long list of dependencies, a list that includes tokio, no small library itself.

In terms of final binary size, the installed size of the curl package on my system, which includes both the command line tool and development dependencies for libcurl, is 1875.03 KiB.

[0] I'm excluding the dependency on the ca-certificates package, since this only provides the certificate chain for TLS and lots of programs rely on it.

[1] https://crates.io/crates/reqwest/0.11.24/dependencies

[2] https://crates.io/crates/hyper/0.14.28/dependencies

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#80

Post by raoulkent »

cout wrote: post #77
forrestthewoods wrote: post #69

Earlier quoted context omitted.

> is the huge binary size Can you quantify this? How big is too big? Ideally for a real program, and not an experiment to make the tiniest possible program. On my Windows machine ripgrep rg.exe is just 4.2mb. Making that smaller feels irrelevant. I’m not convinced that binary size is a real problem. But I’m open to evidence!

It would be nice if it fit on a standard size 1.44MB floppy, but given that I haven't used a floppy drive in about a decade, yeah I guess it doesn't matter much.

Just out of interest, what kind of systems do you work on if you've been using floppy discs in the last 25+ years?
Post reply on HN