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

BlueOS Kernel – Written in Rust, compatible with POSIX

github.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#51

Post by its-summertime »

kllrnohj wrote: post #17
StopDisinfo910 wrote: post #2

I regularly see articles pop in here about OS development happening in China but I find it very hard to find resource in English about what’s actually happening. Could anyone give an overview of what Huawei and Vivo are doing? I understand it’s mostly RTOS to use on phone. How does it compare to QNX and Linux? Is it as ambitious as Fuchsia? Apparently they are shipping. It’s weird that we have reached a point where t…

It's even harder to get an accurate picture of what Chinese companies are actually doing. Like the wiki page for Huawei's OS Next is pretty incredible. By which I mean, rather actually unbelievable. https://en.m.wikipedia.org/wiki/HarmonyOS_NEXT They created a brand new microkernel with Linux ABI and driver support in containers? Or... did they just slightly fork Linux and pretend they invented it?

Permanent link: https://en.wikipedia.org/wiki/Special:Permalink/1302072064

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#52

Post by MisterTea »

notepad0x90 wrote: post #21

It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space. That way, interesting kernels like this one can just comply with that and the enormous amounts of Linux modules can be ported to comply with that standard so that they can also be loaded by redox, blueos,etc.. But the complication I suppose is data-structures being accessed by drivers that reside in the c…

> It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space.

Plan 9 does this but instead of a binary interface that exposes machine details it hides them behind 9P, a simple RPC file tree protocol. This same protocol is also served by user space programs so it's universal. The benefit of all this is the system is small and very light weight. Its an OS a single human can grok from kernel to user space.

Since 9p abstracts everything it's kernel and language agnostic. A Plan 9 kernel can be written in Rust and serve the same 9P tree to a Plan 9 written in C, Go, Zig, D, etc. The user space drivers and services can also be written in any language as well as the programs accessing them. 9P is machine agnostic so a Plan 9 network can be made of disparate machine architectures letting you mix x86, Arm, Power, Mips, Risc-V, etc. Stupid simple cross compiling is an out of the box feature, just change the objtype env variable.

I can export those devices/services to other systems using 9P, cifs, nfs, and so on. I can export the sound device of a Plan 9 machine using cifs to a Windows box and a Windows program could open that file and play sound by writing 16bit stereo audio to it.

Your data structures are then pretty strait forward, e.g audio(3): "Audio data is a sequence of stereo samples, left sample first. Each sample is a 16 bit little-endian two's complement integer; the default sampling rate is 44.1 kHz." http://man.postnix.pw/9front/3/audio

It's a fantastic concept which frees all the services and hardware from the confines of a old school POSIX/Unix machine. Since Plan 9 in NOT Unix you also don't have to worry about crusty old POSIX. It has its own C dialect that is mostly C99 compliant and a very nice C library that beats smelly old ANSI C. I highly recommend learning how it works and giving it a go. Its not for everyone but man, I really dig how its just a patch-bay of networked 9P stuff. Wiring up a network of machines and hardware is ezpz.

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#53

Post by tssva »

fragmede wrote: post #35
heavyset_go wrote: post #29

Earlier quoted context omitted.

IMO, the reason we have a sea of open source drivers available now is because of the lack of a standard driver interface. If one existed, companies would not be compelled to release their drivers' source, and would just release closed source drivers. As it stands, kernel drivers must be open source because the kernel API/ABI changes, and drivers must be recompiled against new kernel releases. It's infeasible to relea…

> It's infeasible to release a compiled driver .ko and have it work with new kernel releases. It's not. At Ksplice we had a build farm and whenever a supported distro would release a new kernel, we would generate new .ko files for that kernel, usually within 24 hours. It was a lot of work, and very much specific to the Ksplice product. These days, between docker and DKMS, and limiting yourself to supporting a specifi…

I’m confused. That fact that you had to recompile for each new kernel reinforces the quote you are seeking to challenge.

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#54

Post by StopDisinfo910 »

kllrnohj wrote: post #50
usamoi wrote: post #49

Earlier quoted context omitted.

Well, it is clear that they have a new definition of a microkernel, since there are now more new technologies that achieve isolation without compromising performance. Microkernel vs monolithic kernel is more of a marketing rhetoric than technical differences.

> Microkernel vs monolithic kernel is more of a marketing rhetoric than technical differences. It's not, they have meanings and they can't just make up something different and pretend it's a microkernel when it isn't. That doesn't make it bad, it's just not what they are claiming. It also obviously isn't IPC, despite their continued use of the term throughout. Also their isolation says it's ARM Watchpoint which is a…

You can read the slide deck and the paper. They are pretty transparent about what they do. The whole point is how they tried to adapt microkernel concepts while still retaining the required performance.

They address at length why they don't use a traditional IPC for the most sollicited part of the kernel.

It being or not being a microkernel is not in itself a very interesting take. What's interesting is how useful or not what they do is.

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#55

Post by MisterTea »

rbanffy wrote: post #38
6r17 wrote: post #3

Earlier quoted context omitted.

I think there might be more of this coming. The era where US was leading everything and expecting everyone to be a good boy who report everything is long gone due to the current state of affairs in the tech world. I'm not Chinese but I can only support such efforts that make everyone less reliable on main actors. That said they even share their work so it's not like they are going full mute.

China's emergence was inevitable - they have the numbers. Last one I heard was 200 million people in STEM careers alone. That's more than the entire US workforce. I expect technological development to explode and my advice is for anyone interested in it to learn Mandarin. Including myself.

> I expect technological development to explode and my advice is for anyone interested in it to learn Mandarin. Including myself.

My father said the exact same thing in the 80's but it was Japanese.

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#56

Post by MisterTea »

Beijinger wrote: post #11
mrbluecoat wrote: post #7

From their website (translated): Blue River Operating System 2 is the industry's first operating system written in the Rust language from the kernel to the system framework. A series of security features of the Rust language can detect security vulnerabilities caused by improper memory use during the compilation stage, making it inherently more secure from the source.

Wasnt Harvey OS written in Rust?

No, that's R9: https://github.com/r9os/r9 (edit: proper r9 project link)

Harvey is Plan 9 built with a GCC/Clang tool chain instead of the Plan 9 tools. AFAIK both projects are abandoned (edit: R9 might still be alive) and most devs have moved on to 9front which is a modern fork of Plan 9.

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#57

Post by fithisux »

notepad0x90 wrote: post #21

It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space. That way, interesting kernels like this one can just comply with that and the enormous amounts of Linux modules can be ported to comply with that standard so that they can also be loaded by redox, blueos,etc.. But the complication I suppose is data-structures being accessed by drivers that reside in the c…

No standard interface but open documentation suitable for developers and an attempt to minimize differences

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#58

Post by fragmede »

tssva wrote: post #53
fragmede wrote: post #35

Earlier quoted context omitted.

> It's infeasible to release a compiled driver .ko and have it work with new kernel releases. It's not. At Ksplice we had a build farm and whenever a supported distro would release a new kernel, we would generate new .ko files for that kernel, usually within 24 hours. It was a lot of work, and very much specific to the Ksplice product. These days, between docker and DKMS, and limiting yourself to supporting a specifi…

I’m confused. That fact that you had to recompile for each new kernel reinforces the quote you are seeking to challenge.

What definition of "infeasible" are you using?

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#59

Post by heavyset_go »

fragmede wrote: post #35
heavyset_go wrote: post #29

Earlier quoted context omitted.

IMO, the reason we have a sea of open source drivers available now is because of the lack of a standard driver interface. If one existed, companies would not be compelled to release their drivers' source, and would just release closed source drivers. As it stands, kernel drivers must be open source because the kernel API/ABI changes, and drivers must be recompiled against new kernel releases. It's infeasible to relea…

> It's infeasible to release a compiled driver .ko and have it work with new kernel releases. It's not. At Ksplice we had a build farm and whenever a supported distro would release a new kernel, we would generate new .ko files for that kernel, usually within 24 hours. It was a lot of work, and very much specific to the Ksplice product. These days, between docker and DKMS, and limiting yourself to supporting a specifi…

Very cool, but I think that points to the impracticality of releasing drivers like that when it comes to distributing them to end users.

Re: BlueOS Kernel – Written in Rust, compatible with POSIX

#60

Post by fragmede »

heavyset_go wrote: post #59
fragmede wrote: post #35

Earlier quoted context omitted.

> It's infeasible to release a compiled driver .ko and have it work with new kernel releases. It's not. At Ksplice we had a build farm and whenever a supported distro would release a new kernel, we would generate new .ko files for that kernel, usually within 24 hours. It was a lot of work, and very much specific to the Ksplice product. These days, between docker and DKMS, and limiting yourself to supporting a specifi…

Very cool, but I think that points to the impracticality of releasing drivers like that when it comes to distributing them to end users.

End users having to connect to the Internet to download the right drivers seems impractical?
Post reply on HN