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

Asterinas: A new Linux-compatible kernel project

lwn.net

Post reply on HN
Print view View original

71–80 of 81 posts

Re: Asterinas: A new Linux-compatible kernel project

#71

Post by eikenberry »

pxc wrote: post #69
weinzierl wrote: post #24

This is an interesting approach, and I wish it will succeed. I am still skeptical. In the late 90s or early 2000s Linus was interviewed on TV and what he said stuck with me to this day. When asked about competitors he roughly said: No one likes writing device drivers and as long no one young and hungry comes along who is good at writing device drivers I am save. I think he was already well aware at that time that kee…

> I think he was already well aware at that time that keeping the driver interface unstable is his moat. Does Linus have/want a moat? He's not a tech startup founder. He's a kernel hacker who has had success beyond his wildest dreams, and whose needs will be met for the rest of his working life no matter what happens. It seems like projection to talk about this aspect of the kernel as if it's some intentional strateg…

I don't believe he wanted or intended a moat. The drivers need to be in the kernel to have a working kernel, that is a kernel that actually runs on the hardware. Move the drivers out of the kernel and Linux would have died long ago as there would have been a proliferation of proprietary drivers that stopped being maintained once the hardware was no longer on sale. And poor driver support is why no other kernel has taken root.

Re: Asterinas: A new Linux-compatible kernel project

#72

Post by pxc »

eikenberry wrote: post #71
pxc wrote: post #69

Earlier quoted context omitted.

> I think he was already well aware at that time that keeping the driver interface unstable is his moat. Does Linus have/want a moat? He's not a tech startup founder. He's a kernel hacker who has had success beyond his wildest dreams, and whose needs will be met for the rest of his working life no matter what happens. It seems like projection to talk about this aspect of the kernel as if it's some intentional strateg…

I don't believe he wanted or intended a moat. The drivers need to be in the kernel to have a working kernel, that is a kernel that actually runs on the hardware. Move the drivers out of the kernel and Linux would have died long ago as there would have been a proliferation of proprietary drivers that stopped being maintained once the hardware was no longer on sale. And poor driver support is why no other kernel has ta…

> Move the drivers out of the kernel and Linux would have died long ago as there would have been a proliferation of proprietary drivers that stopped being maintained once the hardware was no longer on sale.

Isn't this basically the situation on Android?

Re: Asterinas: A new Linux-compatible kernel project

#74

Post by herewulf »

Joker_vD wrote: post #21
uncircle wrote: post #19

Earlier quoted context omitted.

There are hordes of developers completely dismissing the idea of microkernels with no serious argument other than "lmao didn't Linus destroy Tanenbaum that one time?" Designing a modern and secure kernel in 2025 as a monolith is a laughable proposition. Microkernels are the way to go.

> Designing a modern and secure kernel in 2025 as a monolith is a laughable proposition. I've seen this exact opinion before, only the year in it was "1992". And yet Linux was still made and written regardless of it.

Point taken but at that time there was no other free (as in beer and freedom) "UNIX" kernel?

Someone may come along and correct me about BSD. Apologies I'm not super familiar with it's history.

Re: Asterinas: A new Linux-compatible kernel project

#75

Post by kvdveer »

tuna74 wrote: post #66
tatetian16 wrote: post #29

Earlier quoted context omitted.

> keeping the driver interface unstable is his moat Maybe we will have young and hungry AI-for-system researchers who would like to take on the job of developing AI agents that translate Linux drivers in C to Asterinas ones in (safe) Rust. Another feasible approach is to reuse Linux drivers by running a Linux kernel inside some kind of isolated environments. For example, the HongMeng kernel leverages User-Mode Linux…

If you port drivers from Linux those drivers would have to be GPLv2-licensed.

That needn't be a problem, assuming the linking-clause of the GPL2 doesn't extend to device drivers. Gpl2 doesn't extend to userspace processes linking into the kernel, so maybe?

Re: Asterinas: A new Linux-compatible kernel project

#76

Post by SR2Z »

pxc wrote: post #72
eikenberry wrote: post #71

Earlier quoted context omitted.

I don't believe he wanted or intended a moat. The drivers need to be in the kernel to have a working kernel, that is a kernel that actually runs on the hardware. Move the drivers out of the kernel and Linux would have died long ago as there would have been a proliferation of proprietary drivers that stopped being maintained once the hardware was no longer on sale. And poor driver support is why no other kernel has ta…

> Move the drivers out of the kernel and Linux would have died long ago as there would have been a proliferation of proprietary drivers that stopped being maintained once the hardware was no longer on sale. Isn't this basically the situation on Android?

They're still in the kerenel AFAIK, but you need to compile the kernel specifically with a bunch of source-restricted or binary blobs to get things to work.

They're not open and maintained as part of the broader kernel release which is why the driver situation degrades so quickly once the hardware is no longer actively supported.

Re: Asterinas: A new Linux-compatible kernel project

#77

Post by eMPee584 »

reactordev wrote: post #36
tatetian16 wrote: post #29

Earlier quoted context omitted.

> keeping the driver interface unstable is his moat Maybe we will have young and hungry AI-for-system researchers who would like to take on the job of developing AI agents that translate Linux drivers in C to Asterinas ones in (safe) Rust. Another feasible approach is to reuse Linux drivers by running a Linux kernel inside some kind of isolated environments. For example, the HongMeng kernel leverages User-Mode Linux…

This is the future. Hardware has already standardized more towards USB HID than in previous decades, Linus interview included. When AI can develop these device drivers based on just probing the HID info, we’ll be on Cloud9. Because maybe then, we’ll get the year of the Linux desktop.

Yeah, it's very easy. Real devices usually adhere to the specs.. only very few exceptions: https://github.com/torvalds/linux/blame/master/drivers/hid/h... .. /s

Re: Asterinas: A new Linux-compatible kernel project

#78

Post by qalmakka »

kvdveer wrote: post #75
tuna74 wrote: post #66

Earlier quoted context omitted.

If you port drivers from Linux those drivers would have to be GPLv2-licensed.

That needn't be a problem, assuming the linking-clause of the GPL2 doesn't extend to device drivers. Gpl2 doesn't extend to userspace processes linking into the kernel, so maybe?

Yeah but unless the drivers run like microkernel services in a separate userspace, the GPL applies to anything you link into your kernel

Re: Asterinas: A new Linux-compatible kernel project

#79

Post by DinoNuggies45 »

defrost wrote: post #5
DinoNuggies45 wrote: post #3

[flagged]

A page of written text you mean? Likely a text editor or some web publishing tool. All of which raises a real question about your question and all your other recent "questions" - https://news.ycombinator.com/threads?id=DinoNuggies45 is this just AI output generated to apear engaged while launching YetAnother beachhead account to gang upvote submissions, influence voting, etc.

No I was being genuine…I’m new to code and don’t have a clue on how to make something like that. Was it not coded at all? I use docs and can never get it to look like that. Oh and what’s a “beachhead”?

Re: Asterinas: A new Linux-compatible kernel project

#80

Post by pas »

winternewt wrote: post #17
josephg wrote: post #13

Earlier quoted context omitted.

> I thought newer microkernels... Reduced that? Fixed it? I forget, I just had the impression it wasn't actually that bad SeL4 is a microkernel like this. They’ve apparently aggressively optimized IPC far more than Linux ever has. Sending a message via sel4 ipc is apparently an order of magnitude or two faster than syscalls under Linux. I wouldn’t be surprised if most programs performed better under sel4 than they do…

The trick with L4 is they treat IPC basically like syscalls. Arguments are left on CPU registers instead of serializing them to a message buffer. The only significant work performed is a change of virtual memory map. The called process continues execution within the time slice of the caller, instead of waiting for the thread scheduler or using synchronization primitives. While some of this could possibly be achieved…

so simple recompilation can speed things up? sounds amazing. (but of course, can it?) also, it sounds a bit like restartable sequences (from Google).
Post reply on HN