I maintain LuaJIT syscall bindings https://github.com/justincormack/ljsyscall - they cover quite a lot, namespaces, netlink and so on. I spent quite a bit of time making them more intuitive than the raw bindings, with consistent error handling, also namespacing constants and so on. It is definitely useful to have these types of interfaces not in C.
Rust and Nix = easier Unix systems programming
41–50 of 85 posts
Re: Rust and Nix = easier Unix systems programming
#42In reliability theory "X failed" is a poor error message. What we want to know is which failure mode has been triggered. The function of kill is to kill a given pid, so there are two failure modes : "the pid didn't exist" or "the pid didn't die"
kill(2) unlike it's name actually sends any signal to a pid, not only SIGKILL. Other signals are used for various purpose. SIGINT is for example used when using Ctrl-C on a terminal.
Re: Rust and Nix = easier Unix systems programming
#43I can't help but think they're trying to fix something that isn't broken at all. Adding new abstraction layers rarely helps when doing systems programming. You (as in "the developer") want to be as near to the machine as possible. C does this pretty well. Perhaps I'm just getting old :-(
Then you are missing the whole point of Rust. The point of Rust IS to allow you to be close to the machine but while you maintain much higher level of safety. Rust is designed to do this with little overhead. In this day and age with big software packages, security being an increased concern it really is high time programming languages do more to help us avoid bugs which expose us to hackers and crackers. I do have a…
The proposition that Rust is offering is not new. In the 90s Modula-2 was touted as "a better, safer way" of doing system programming than C. It failed to get traction outside of education because it failed to offer a compelling reason for people to migrate. Those that do not study history are doomed to repeat its mistakes.
In the example given it's possible to write a similar library in C to protect against unwanted side effects or bad API design. I'm sure several have been written over the years.
Rust is a great language with lots of improvements over other system programming languages, but that is not going to be enough to get people to switch. You have to show that it's good enough to be worth throwing away 40 odd years of experience and well understood best practice. Something that is going to take a long time and big public projects to do. If just being better was good enough Plan 9 would have been a roaring success and Linux (if it happened) would probably be a footnote in history.
C and UNIX have survived as long as they have not because better alternatives haven't come along, but because the alternatives haven't offered a compelling reason to switch. Unfortunately at least now Rust is falling into the same category.
See also: Niccolo Machiavelli, The Prince
Re: Rust and Nix = easier Unix systems programming
#44This gets me thinking how awesome it would be to have functional programming on *nix systems, like Haskell (specifically). At least then it might be forcibly designed to be made more useful and ultimately get more people on board. One can dream.
Re: Rust and Nix = easier Unix systems programming
#45Earlier quoted context omitted.
> It's not even clear to me that there's any overhead to the Rust version. There is a slight bit of stack overhead: Option is at least {tag:u8, {tag:u8, pid:i32}}, and due to alignment constraints it's actually {tag: u32, {tag: u32, pid: i32 }}). A nonzero wrapper[0] would allow folding either ForkResult or Option into a 0-valued pid_t and remove one level of tagging: http://is.gd/yxStW1 Beyond that you'd need genera…
We do have a planned optimization that would fold the tags for cases like `Option ` to give a word pair, which should be returned in %eax:%edx (or %rax:%rdx).
Really? That's exciting. Missed enum layout optimizations are one of my few issues with Rust right now.
Re: Rust and Nix = easier Unix systems programming
#46I was very confused. I thought this had something to do with Rust and nix[1]. [1]: https://nixos.org/nix/
Same here. To be fair the Nix package manager has a name that is actively harming its growth since most people think *nix as in unix when you say nix.
Google does too to an extent, making troubleshooting more of a pain than it should be.
Re: Rust and Nix = easier Unix systems programming
#47Earlier quoted context omitted.
struct fork_status { enum { ERROR, PARENT, CHILD } state; int ret; }; I think the point of tagged unions (as in OP's example) is that you cannot access `child` if the call failed. Your example does have an exhaustive check (by a compiler warning), but it doesn't prevent you from misinterpreting `ret` as a pid. Does C have a method to enforce this restriction?
Well pids should be pid_t not int. System calls should really return two values, return value and errno, but C doesn't handle that very well either.
> Well pids should be pid_t not int.
pid_t isn't a newtype, it's just a typedef, so that doesn't really make a difference.
> System calls should really return two values, return value and errno, but C doesn't handle that very well either.
Most system calls want to return either, not both. And C doesn't handle that at all.
Re: Rust and Nix = easier Unix systems programming
#48Earlier quoted context omitted.
It's not even clear to me that there's any overhead to the Rust version. Checking error codes that should be checked isn't overhead. Checking them inefficiently would be overhead, but the Rust version looks like it should compile down to something pretty similar to what the equivalent C switch blocks would produce.
> It's not even clear to me that there's any overhead to the Rust version. There is a slight bit of stack overhead: Option is at least {tag:u8, {tag:u8, pid:i32}}, and due to alignment constraints it's actually {tag: u32, {tag: u32, pid: i32 }}). A nonzero wrapper[0] would allow folding either ForkResult or Option into a 0-valued pid_t and remove one level of tagging: http://is.gd/yxStW1 Beyond that you'd need genera…
Theoretically It should be possible to have a union based on the value of the ints {-1, 0, positive}, which should use only one 32bit integer.
Re: Rust and Nix = easier Unix systems programming
#49In reliability theory "X failed" is a poor error message. What we want to know is which failure mode has been triggered. The function of kill is to kill a given pid, so there are two failure modes : "the pid didn't exist" or "the pid didn't die"
"kill failed" isn't actually the message which is printed. What you get is thread ' ' panicked at 'kill failed: Sys(ESRCH)', ../src/libcore/result.rs:746 So you know that it failed because of ESRCH (no such process).
Ah, that makes much more sense, thanks
Re: Rust and Nix = easier Unix systems programming
#50I always find it a bit unfair when I see sloppy C programs used for shock value. What if the Rust developer uses fork().unwrap_or(default_value) in a hurry, or writes if let Some(child) = fork() { do_only_child_stuff(); } else { do_only_parent_stuff(); } or if let Some(ForkResult::Child) = fork() { do_only_child_stuff(); } else { do_only_parent_stuff(); } Now, if you're about to tell me that the examples above are to…
> What if the Rust developer uses fork().unwrap_or(default_value) in a hurry The point here is that the language's tools and APIs can significantly better drive the developer towards the safe/right solution, that's a large point of type theory and static type systems after all. In this case rust's type system is used to split out the various "result cases" and notify the developer upfront of the various cases to hand…
This has been proven to be wrong over and over again with the many variations of languages that came after C. Newer "safer" languages don't improve bugs