Maestro: A Linux-compatible kernel in Rust

Post by kybernetikos » Wed, Jan 03, 2024, 4:22 PM UTC

baq wrote: post #153

jodrellblank wrote: post #142

Earlier quoted context omitted.

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…

the file is inconsequential. it could be any other universal abstraction, e.g. HTTP POST. it's just something that every program running on a computer knows how to do, so why bother with special APIs you have to link against if you can just write to a file? (note you can still develop those layers if you wish, but you can also write a device driver in sh if you wish, because why not?)

Post by madushan1000 » Wed, Jan 03, 2024, 4:27 PM UTC

sylware wrote: post #99

madushan1000 wrote: post #72

Earlier quoted context omitted.

What do you mean? most complicated parts of the gpu driver are in userland and handled by Mesa or equivalent. Kernel drivers expose a standard interface(DRM) which userspace drivers use to upload compiled gpu programs and manage gpu memory. Also, linux is not tied to gcc extensions, it can be compiled with llvm(clang) for a long time now.

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.

Post by Arainach » Wed, Jan 03, 2024, 4:29 PM UTC

dark-star wrote: post #37

What a cool little project. It's astonishing how far this can boot with less than a third of the syscalls of Linux implemented. However, my guess is that the ones that are missing are the more complicated ones. The TTY layer, for example, looks rather basic at the moment. Getting this right will probably be a lot of work. So don't hold your breath for Maestro running your Linux applications in the next 3 years or so…

Post by [deleted] » Wed, Jan 03, 2024, 4:33 PM UTC

TheHiddenSun wrote: post #224

llenotre wrote: post #164

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.

Post by MobiusHorizons » Wed, Jan 03, 2024, 4:36 PM UTC

sylware wrote: post #149

MobiusHorizons wrote: post #127

Earlier quoted context omitted.

RISC-v assembly is not substantially easier to write than any other assembly. RISC assemblies in general (aka MIPS, Arm, RV64 etc) require more instructions to accomplish the same tasks. I would argue they are designed with compilers in mind more than human authors. Older assemblies expected the programmer to be programming in assembly directly, which is why they allow you to express your intent more directly than RI…

RISC-V is a modern load-store ISA. Is is very clean, much more than the mess of x86_64 for instance. It is actually better to write RISC-V than x86_64, even if the later is CISC.