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

131–140 of 229 posts

Re: Hobby x86 kernel written with Zig

#131

Post by AndyKelley »

jackhalford wrote: post #83
archsurface wrote: post #70

The hello world examples for master and 0.5.0 seem quite different - any trouble keeping up with the changes?

migration from 0.4 to 0.5 was ok. AFAICT there the big change for 0.6 syntax wise is the drop or varargs in favour of tuples. I'll take some time to do the switch when 0.6 hits but I'm confident it won't take long because of how concise the language is.

0.6.0 is scheduled for April 13, 2020. Let's make sure your project builds successfully and correctly with master branch 1-3 weeks before that, and I'll prioritize any bugs before the release that affect you.

(This goes for all zig community members with active projects)

Re: Hobby x86 kernel written with Zig

#132

Post by adamrezich »

rehemiau wrote: post #5
jackhalford wrote: post #4

Hi, author here! I've just finished writing the pre-emptive multitasking [0](only round robbin though, nothing fancy). I'm currently writing an ATA driver [1], the idea is to implement ext2. I used to do this in Rust but I switched to zig for maintainability and readability over Rust. It seems that with `comptime` I'm able to make a lot of things optimal. Overall I have to say kernel programming is _hard_ but very re…

Looks awesome! Planning to do a similar thing in Jai once it comes out

There's still zero evidence that the compiler or language ever have been or ever will be called "Jai," aside from the fact that it is the tenuous file extension being used in development streams.

Re: Hobby x86 kernel written with Zig

#133

Post by pron »

apta wrote: post #130
pron wrote: post #122

Earlier quoted context omitted.

> We have a pretty good answer to the question "is ASan sufficient to prevent memory safety problems in practice" That is not the question we're interested in answering, and elimination of all memory errors is no one's ultimate goal, certainly not at any cost. By definition, unsound techniques will let some errors through. The question is which approach leads to an overall safer program for a given effort, and soundn…

> As someone who currently mostly programs in C++, lack of memory safety barely makes my top three concerns. Isn't having a UB-free JVM a noteworthy goal though? Especially if it gets used in life-critical systems such as avionics or autonomous cars.

UB-freeness is not a goal in-and-of-itself. It's shorthand for a certain kind of technical (i.e. non-functional) correctness, which, in turn, is related in some ways to functional correctness, and it's improving functional correctness (and I include security here) that's the goal. Is the most effective way to achieve that is by working to completely eliminate undefined behavior? I'm not at all sure.

Re: Hobby x86 kernel written with Zig

#134

Post by eli_gottlieb »

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…

Can Zig's enums and tagged unions be used to write algebraic data types?

Re: Hobby x86 kernel written with Zig

#135

Post by zozbot234 »

DSMan195276 wrote: post #129
rapsey wrote: post #58

Earlier quoted context omitted.

The ammount of unsafe blocks is pretty small compared to the rest of the code. Which means those parts can be reviewed more extensively. If anything your argument is pretty goofy.

> The ammount of unsafe blocks is pretty small compared to the rest of the code. Which means those parts can be reviewed more extensively. If anything your argument is pretty goofy. I've talked about this at length before, but just because you have 'less' `unsafe` code does not mean you code is any better off. Very few operations are actually `unsafe`, and you're still not allowed to break any of the (poorly or not d…

If you aren't making a safe abstraction around your unsafe code, you're supposed to mark the surrounding function "unsafe" as well, and document its expected constraints in a 'Safety' comment block. In fact, you're supposed to do the same for any piece of code that cannot provide safety guarantees about its use of 'unsafe' features. 'Plain' unsafe{ } blocks should only be used as part of building a safe abstraction.

Re: Hobby x86 kernel written with Zig

#136

Post by rehemiau »

adamrezich wrote: post #132
rehemiau wrote: post #5

Earlier quoted context omitted.

Looks awesome! Planning to do a similar thing in Jai once it comes out

There's still zero evidence that the compiler or language ever have been or ever will be called "Jai," aside from the fact that it is the tenuous file extension being used in development streams.

It's the best short name we can use right now so it's the one we should use IMO. If it gets a different name, we'll start calling it differently, I don't mind.

Re: Hobby x86 kernel written with Zig

#137

Post by nimmer »

Touche wrote: post #109
mratsim wrote: post #84

Earlier quoted context omitted.

You call malloc/free, or if working with GPU cudaMalloc/free. You can write your own memory pool or object pools, you can use destructors, and even implement your own reference counting scheme. This is what I use for my own multithreading runtime in Nim and the memory subsystem makes it faster and more robust than any runtime (including OpenMP and Intel TBB) that I've been benchmarking against, see memory subsystem d…

Does the standard library use malloc/free or does it depend on the GC? This is the part that's puzzling to me, if the stdlib depends on GC then it's harder to say that GC is optional. Technically optional but not super practical.

The majority of stdlib modules does not depend on GC.

Also, the new ARC memory manager replaces GC and can run in a kernel.

Re: Hobby x86 kernel written with Zig

#138

Post by nickpsecurity »

jackhalford wrote: post #90
simias wrote: post #79

Earlier quoted context omitted.

It's true that for bare metal programming Rust is quite far from 1.0. You can't even do inline assembly in stable rust... Arbitrary sized integers do sound very convenient, although I guess the counterargument would be that they simply can't map to machine types so you'll have to have magic behind the scenes which may not make complete sense in low level languages. Still, C has bitfields in structs which are sort of…

Ok maybe I was user pointers wrong in Rust. And I must confess that I never really understood lifetimes either, however * I don't think that low level code needs to be "messy", and * I don't think that adding an abstraction on top solves anything complexity wise. For memory paging I used to have a whole library in Rust that handled hierarchy of page tables with very abstract pagetable classes and interfaces [0]. Now…

You might find it helpful to look at Redox OS and Tock to see how they're handling kernel development in Rust. May or may not be easier than what you described.

https://www.redox-os.org/

https://www.tockos.org/

Re: Hobby x86 kernel written with Zig

#139

Post by swsieber »

DSMan195276 wrote: post #129
rapsey wrote: post #58

Earlier quoted context omitted.

The ammount of unsafe blocks is pretty small compared to the rest of the code. Which means those parts can be reviewed more extensively. If anything your argument is pretty goofy.

> The ammount of unsafe blocks is pretty small compared to the rest of the code. Which means those parts can be reviewed more extensively. If anything your argument is pretty goofy. I've talked about this at length before, but just because you have 'less' `unsafe` code does not mean you code is any better off. Very few operations are actually `unsafe`, and you're still not allowed to break any of the (poorly or not d…

It doesn't mean your code is better off, but it makes auditing your code a lot easier. Rust gives you lots of good tools so that you can fence in your unsafe and restrict it to a module (source code file), such that if you audit the module containing the unsafe, you should be good to go.

Re: Hobby x86 kernel written with Zig

#140

Post by knebulae »

I tried to do this with Zig about 13 months ago. It was not where it needed to be at that time; the biggest impediments were its rudimentary handling of C pointers to one vs pointers to many (which has long since been fixed), and its meta programming issues (lack of a macro language or pre-processor) that made OS development tedious. I have not revisited it as much as I would have liked simply because I chose to step back a bit on implementation and focus on theory.

I'm pulling for Andrew. He busts his rear-end, livestreams, and is generally a good dude. Zig has a TON of potential.

Post reply on HN