Live data from Hacker News

Maestro: A Linux-compatible kernel in Rust

blog.lenot.re

231–240 of 380 posts

Re: Maestro: A Linux-compatible kernel in Rust

#231

Earlier quoted context omitted.

Care to elaborate on this? I clearly understand nothing of this, but it always felt confused about it. Why won't Linux aim for ABI stability? Wouldn't that be a win for everyone involved?

The Linux Kernel Driver Interface (all of your questions answered and then some) https://github.com/torvalds/linux/blob/master/Documentation/...

Cyclic logic that says you're wrong for wanting a stable kernel interface, because the kernel keeps changing so the solution is to just get your code merged into mainline. As a tautology, it's true, but it's also a cover for "because we don't want to".

See Windows or android GKI for existence proof that it can be done if so motivated.

Re: Maestro: A Linux-compatible kernel in Rust

#232

So many thank to all of you for your support! This project has represented a lot of efforts for me and it means a lot! Right now the website seems to be pretty slow/down. There is a lot of traffic, which was not expected. I also suspect there might be a DoS attack going on. I will try to make it work better when I get home! (I am currently at work so I cannot give much attention to it right now) Sorry for the inconve…

Please test your website on mobile. The navbar takes like 33% screen state and can't be removed. I never understand why people want to make them sticky and steal valuable reading screen space. You can, if you want, always scroll to the top in like 300 ms.

I agree, I have the Kill Sticky extension installed on my mobile browser and it works great for these kinds of situations.

Re: Maestro: A Linux-compatible kernel in Rust

#233
post #231

Earlier quoted context omitted.

The Linux Kernel Driver Interface (all of your questions answered and then some) https://github.com/torvalds/linux/blob/master/Documentation/...

Cyclic logic that says you're wrong for wanting a stable kernel interface, because the kernel keeps changing so the solution is to just get your code merged into mainline. As a tautology, it's true, but it's also a cover for "because we don't want to". See Windows or android GKI for existence proof that it can be done if so motivated.

From what I understood, I think the big difference here is the human factor: Windows and Android are maintained by employees, who have no choice but to work on things even if they don't like doing it. Linux on the other hand is a collective effort of people doing what they want to do on their free time.

Re: Maestro: A Linux-compatible kernel in Rust

#234

Earlier quoted context omitted.

Drivers are the tough part and the lack of a stable interface in Linux makes them hard to reuse.

There have been attempts to create kernel-agnostic interfaces for drivers such as: https://en.wikipedia.org/wiki/Uniform_Driver_Interface For my case, I am planning to re-implement them. I like doing this. I sure am not going to be able to re-implement everything myself though. I will concentrate on what I need, and I will consider implementing others if anyone else other than me is willing to use the OS (which would…

You can implement a virtual machine monitor (e.g. KVM) and then launch a Linux virtual machine to run drivers you lack.

Re: Maestro: A Linux-compatible kernel in Rust

#235
post #96

This sounds more than great. Unrelated but at same time related, feel your self absolutelly free to ignore this message, Linux needs a HISP with firewall. I comment it here because this need to be supported by a/the kernel, its needed to limit the functions that allow process injections, and also a way for to canalize all the process executions in a supervised mode. As an [put operative system name here] user, I need…

It already exists: SELinux or AppArmor. They build on infrastructure that allows implementing other solutions to that effect.

However, on a typical system there is so much going on that this is unlikely to be of much use to anybody not willing to just spend their time reviewing arcane internals of their applications. The above does not how I'd want to spend my day at the computer.

Android and iOS presents a middle ground. But even their requests get tiresome after some time, and users are pretty quickly seduced to just allow everything.

Re: Maestro: A Linux-compatible kernel in Rust

#238

Earlier quoted context omitted.

I wish L4 had taken off for general purpose computing. That and Plan9 are things I'd really like to try out but I don't have space to fit operating systems in amongst the other projects. They both strike me as having the Unix nature, either "everything is messages in userspace processes" or "everything is a file."

I don't think I've ever seen an argument for why "everything is a file" is a desirable thing. It seems like a kitchen where "everything is a bowl". Fine when you want to eat cereal, mix a cake, do some handwashing up, store some fruit; tolerable when you want to bake a cake in the oven. Intolerable when you've got a carrot in a bowl-shaped chopping board and you've got to peel and cut it using a bowl. Why in principl…

> I don't think I've ever seen an argument for why "everything is a file" is a desirable thing.

A file system is a tree of named objects. These objects are seamlessly part of the OS and served by a program or kernel driver called a file server which can then be shared over a network. Security is then handled by file permissions so authentication is native through the system and not bolted on. It fits together very well and removes so much pointless code and mechanisms.

A great example is a old uni demo where a system was built to control X10 outlets and switches (early home automation gear). Each device was a file in a directory tree that represents a building with sub directories for floors and rooms - e.g. 'cat /mnt/admin-building/2fl/rm201/lights' would return 'on' or 'off' (maybe it's a dimmer and its 0-255, or an r,g,b, value or w/e, sky's the limit, just put the logic in the fs). To change the state of the lights you just echo off >/mnt/admin-building/2fl/rm201/lights.

Now you can make a script that shuts all the lights off in the building by walking directories and looking for "lights" then writing off to those files. Maybe it's a stage, all your lights are on DMX and you like the current settings so then you 'tar -c /mnt/auditorium/stage/lighting|gzip >student_orientation_lighting_preset.tar.gz' and do the reverse over-writing all the archived settings back to their respective files. You could even serve those files over smb to a windows machine and turn lights on and off using notepad or whatever. And the file data doesn't have to be text, it could be binary too. It's just that for some things like the state of lights, temperature or w/e can easily be stored and retrieved as human readable text.

That is the beauty and power of 9p - its removes protocol barriers and hands you named objects seamlessly integrated into your OS which you can read/write using regular every day tools. It's a shame so many people can't grasp it.

Re: Maestro: A Linux-compatible kernel in Rust

#240
post #99

Earlier quoted context omitted.

What you said is mostly wrong. The kernel part of the GPU driver is massive. It is well known, maybe you were misguided: for instance the AMD GPU drivers are gigantic compared to the actual kernel. clang(llvm) is playing cat and mouse with gcc extensions and recent ISO C tantrums which creeps into the kernel:Linus T. does not resist those, he does resist only the linux useland ABI(syscalls) breakers.

It's also well known the driver is massive because there are hundreds of thousands of lines of auto-generated register access code in there. Not because it's inherently very complex.

And again you are wrong. It was debunked not a long time ago, and I think it was here on HN. The AMD drivers, kernel side, are still gigantic even excluding the generated register descriptions. Is this what we call a AI lie?

But where you may be right: it seems nvidia hardware programming interface is much cleaner than AMD one and may require much much less code.

Post reply on HN