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

Hobby x86 kernel written with Zig

github.com

Post reply on HN
Print view View original

161–170 of 229 posts

Re: Hobby x86 kernel written with Zig

#161

Post by Cyph0n »

cies wrote: post #51
woodrowbarlow wrote: post #48

Earlier quoted context omitted.

not if you have to keep using unsafe blocks.

As an ancestor in this thread pointed out: it's hard/impossible to go without unsafe in a kernel. Proof (and they have a policy to only use unsafe when not otherwise possible): https://github.com/redox-os/kernel/search?q=unsafe&unscoped_...

I was expecting way more “unsafe” uses than that!

I see two advantages to explicitly marking code as unsafe:

(1) You are very clearly marking the areas of code that are most suspect

(2) You can still have safe code outside of those “unsafe” blocks

Re: Hobby x86 kernel written with Zig

#162

Post by Cyph0n »

celticmusic wrote: post #152
phendrenad2 wrote: post #144

Earlier quoted context omitted.

What I find is that, while Rust unquestionably improves the security of software, the argument that you can minimize unsafe code and thoroughly inspect it doesn't tell the full story, because in my experience people end up writing general-purpose unsafe blocks, and while they are controlled by the "safe" outside, the sequence of actions the "safe" code tells them "unsafe" code to execute can lead to subtle bugs.

yep, 100% I personally think the Rust community has missed the biggest advantage of unsafe, and that's tooling. Imagine an IDE that could highlight and warn when touching state that is accessed in unsafe blocks, or when state being accessed in unsafe blocks isn't being properly tested. Or tools that kick off notification for a required code review because code that touches state used by an unsafe block got changed. T…

But isn’t the most important step having a compiler-enforced keyword for code that seems to be doing unsafe stuff?

The rest are just plugins and tools that look for said blocks and “do stuff”. I don’t see why these tools should be part of the language.

Re: Hobby x86 kernel written with Zig

#163

Post by sov »

jackhalford wrote: post #28
guggle wrote: post #6

Earlier quoted context omitted.

> I used to do this in Rust but I switched to zig for maintainability and readability over Rust. Can you expand on this ? I'm asking out of curiosity because I want to learn a "system" programming language (for whatever definition there is to this term). So far I briefly tried Rust and Nim and found the former more difficult to read. I know nothing about Zig, how would you place it between these two ?

In general you'll find that zig is easier to read than Rust (see the first version of this project in Rust [0]) because it's a simpler language. For kernel programming this is even more so the case: * zig has native support for arbitrary sized integers. In Rust I used to do bitshifts, Now I just have a packed struct of u3/u5/u7 whatever (see `src/pci/pci.zig`). Of course Rust has a bitflags crate but I didn't find it…

Your point about unsafe pointer handling in Rust is specifically what dissuaded us from using it in an upcoming project. It really feels bad prepending all of the code that you actually care about being safe with `unsafe`.

Re: Hobby x86 kernel written with Zig

#164

Post by pron »

mntmoss wrote: post #159
pron wrote: post #146

Earlier quoted context omitted.

P.S. > Notice that the working approaches have something important in common: a strong system that, given certain assumptions, guarantees the lack of memory safety problems. That's a very good point and I'm not arguing against it. It's just that even if it's true -- and I'm more than willing to concede that it is -- it still doesn't answer the question, which is: what is the best approach to achieving a required leve…

I would like to chime in by noting that Rust's mature form is borne of a very specific scenario, which is the web browser, software so complex that the "zero-cost" element is more like "actually possible to optimize" in practice. And a great deal of that complexity is accidential in some form, a result of accreted layers. And in that respect, it's not really the kind of software anyone needs to aspire to; aspiring to…

I don't take issue with the "zero-cost" part -- Zig and C, like every low-level language, have that -- but with the non-abstraction-"abstraction" part, which is rather unique to C++ and Rust. Rust has become a modern take on C++, and I'm not sure it had to be that for the sake of safety; I think it became that because of what you said: it was designed to replace C++ in a certain application with certain requirements. It's probably an improvement over C++, but, having never been a big fan of C++, it's not what I want from a modern systems programming language. It seems to me that Rust tries to answer the question "how can we make C++ better?" while Zig tries to answer the question "how can we make systems programming better?"

Of course, Zig has an unfair advantage here in that it is not production-ready yet, and so it's not really "out there," and doesn't have to carry the burden of any real software (there's very little software that Rust carries, but it's still much more than Zig). I admit that when Rust was at that state I had the same hopes for Rust as I do now for Zig, so Zig might yet disappoint.

Re: Hobby x86 kernel written with Zig

#165

Post by AndyKelley »

simias wrote: post #153
AndyKelley wrote: post #123

Earlier quoted context omitted.

In Zig they do; here is an example: https://clbin.com/HlJ0X Output: Test [1/1] test "bit field access"... *align(:3:1) u3 All 1 tests passed. Zig's pointer type has optional metadata to describe alignment, sub-byte offset, and SIMD vector element index. This generally makes things just work, and you'll get a compile error if you expected an unadorned aligned pointer. If I were to swap: - fn deref(ptr: var) u3 { + fn…

How do you deal with atomicity though? A big deal in Rust is that you can only have one mutable reference to an object at any given time which prevents all sorts of aliasing issues, but here if you have two mutable fat pointers, one to and and one to b, and you attempt to write them without synchronization you're going to have a big problem, won't you? This is the main risk with bitfields in C, it makes reads and wri…

The builtin functions for atomic operations provided by the language do not allow unaligned pointers, so it would be a compile error.

Re: Hobby x86 kernel written with Zig

#166

Post by steveklabnik »

celticmusic wrote: post #152
phendrenad2 wrote: post #144

Earlier quoted context omitted.

What I find is that, while Rust unquestionably improves the security of software, the argument that you can minimize unsafe code and thoroughly inspect it doesn't tell the full story, because in my experience people end up writing general-purpose unsafe blocks, and while they are controlled by the "safe" outside, the sequence of actions the "safe" code tells them "unsafe" code to execute can lead to subtle bugs.

yep, 100% I personally think the Rust community has missed the biggest advantage of unsafe, and that's tooling. Imagine an IDE that could highlight and warn when touching state that is accessed in unsafe blocks, or when state being accessed in unsafe blocks isn't being properly tested. Or tools that kick off notification for a required code review because code that touches state used by an unsafe block got changed. T…

Those tools exist or are being worked on! Servo (last I checked) uses a “unsafe code was added or modified in this PR, please review extra carefully” bot, and Miri is on its way to becoming a fantastic tool.

Re: Hobby x86 kernel written with Zig

#167

Post by celticmusic »

Cyph0n wrote: post #162
celticmusic wrote: post #152

Earlier quoted context omitted.

yep, 100% I personally think the Rust community has missed the biggest advantage of unsafe, and that's tooling. Imagine an IDE that could highlight and warn when touching state that is accessed in unsafe blocks, or when state being accessed in unsafe blocks isn't being properly tested. Or tools that kick off notification for a required code review because code that touches state used by an unsafe block got changed. T…

But isn’t the most important step having a compiler-enforced keyword for code that seems to be doing unsafe stuff? The rest are just plugins and tools that look for said blocks and “do stuff”. I don’t see why these tools should be part of the language.

I never said they should be part of the language, I said the rust community over-emphasizes the "safe" part of having the unsafe keyword and neglected the part that's actually useful in keeping things safe.

Another poster responded to me stating they are starting to work on those tools, so it looks like the rust community is starting to come around.

It's just that I've seen a lot of people tout the safety of rust as if the unsafe keyword was a panacea that automatically prevented problems. That attitude is really what I was responding to.

Re: Hobby x86 kernel written with Zig

#168

Post by Bekwnn »

swiley wrote: post #15
simias wrote: post #9

Earlier quoted context omitted.

I'm curious too, I'm quite familiar with Rust and never written any Zig in my life so I went digging through the source and I find the syntax remarkably similar for the most part. The only thing that stood out is that apparently you can drop the braces for single-line `if` bodies like in C whereas Rust makes them always mandatory but I'm firmly on Rust's side on this one. The part where Rust can get really messy is w…

If you want more syntax weirdness: tab characters are illegal.

Because the language is attempting to have a standardized formatter. I'm all for it, personally.

Re: Hobby x86 kernel written with Zig

#169

Post by Cyph0n »

celticmusic wrote: post #167
Cyph0n wrote: post #162

Earlier quoted context omitted.

But isn’t the most important step having a compiler-enforced keyword for code that seems to be doing unsafe stuff? The rest are just plugins and tools that look for said blocks and “do stuff”. I don’t see why these tools should be part of the language.

I never said they should be part of the language, I said the rust community over-emphasizes the "safe" part of having the unsafe keyword and neglected the part that's actually useful in keeping things safe. Another poster responded to me stating they are starting to work on those tools, so it looks like the rust community is starting to come around. It's just that I've seen a lot of people tout the safety of rust as…

Ah, gotcha. Yes, improved tooling in this area would add a lot of value to the feature.

Re: Hobby x86 kernel written with Zig

#170

Post by antpls »

jackhalford wrote: post #77
netgusto wrote: post #13

Earlier quoted context omitted.

Bouncing on recently featured HN thread "Hello World": https://drewdevault.com/2020/01/04/Slow.html (and the HN thread: https://news.ycombinator.com/item?id=21954886 ) According to this resource, Zig produces code that is very close to the hand written assembly for the simple use case of outputing "hello world" on the stdout. This is to be taken with a grain of salt though, as of course, caring about the assembly out…

> caring about the assembly output is a spectacular case of premature optimization I don't agree! at least for operating systems. Consider that some operating system code may be run a million times per second, on a million different machines (e.g: block system IO on linux). We very much want our assembly to be pristine in this case. I also like the idea of "optimality" brought forward by zig. In the post you link, th…

> Consider that some operating system code may be run a million times per second, on a million different machines (e.g: block system IO on linux). We very much want our assembly to be pristine in this case.

I would believe that most of the time of a processor is dedicated to run userspace code, not OS code (regarding to the work that must be done). At the end of the day, the OS is "only" a scheduler to share hardware resources between unrelated tasks.

> I like that zig focuses on optimality.

Optimality isn't required in many real world businesses. Optimality is often a tradeoff : with optimality you lose in flexibility. An optimal program with SISD instruction set isn't optimal anymore when SIMD instructions are introduced. Your "optimal" asm program is still optimal on x86, but also totally obsolete because it cannot use the latest NEON instructions from ARM or 64bit instructions.

Post reply on HN