GNU/Hurd Continues Effort To Use NetBSD's Drivers For Better Hardware Support

[phoronix]

Phoronix: GNU/Hurd Continues Effort To Use NetBSD's Drivers For Better Hardware Support

Besides all of the Linux-focused talks at the annual FOSDEM conference, another favorite track of mine is that on micro-kernels and other operating systems. While there wasn't the GNU/Hurd status update in 2022 as there has been in some recent years, there was a talk over GNU/Hurd using NetBSD kernel drivers in order to expand its hardware coverage...

https://www.phoronix.com/scan.php?page=news_item&px=GNU-Hurd-NetBSD-Drivers-2022

[wertigon]

At this point HURD is about as likely to succeed as the resurgence of Amiga. E.g. most people involved are dealing with necrophilia more than anything else.

Now, don't get me wrong, the Microkernel push has it's place, it's just that HURD is going nowhere and this will keep being true for as long as HURD insists on it's original goals (being **THE** GNU kernel). I think HURD should refocus efforts and move to, say, RISC-V or OpenPower, possibly introduce a hardware scheduler and it's own hardware communications bus for IPC. At this stage it's probably less painful to do a ground up redesign using lessons learned from other Microkernel OSes, like HelenOS and L4. Or simply adopt a fork of those projects as the new GNU HURD path.

Of course, these days GNU as it was originally envisioned is pretty much dead anyways; some bits remain like glibc, bash and some shell utilities, the rest has been essentially superceded by Systemd, Xorg and Linux.

[sinepgib]

I think HURD should refocus efforts and move to, say, RISC-V or OpenPower, possibly introduce a hardware scheduler and it's own hardware communications bus for IPC.

This would make it even less likely to succeed. With this path you now depend on hardware makers to be interested in microkernels enough to actually mass produce chips with the Hurd extension, assuming they can make it general enough to not require interest in Hurd specifically (won't happen). It also makes it less flexible and less free, as you can't do much about the hardware once it's there. Not only that, but now you start depending on platform drivers that will surely pile up as new specifications get developed, something undesirable from a microkernel POV.
Plus, it doesn't matter how good and open RISC-V and OpenPOWER are, the dominant platforms are still ARM and x86, so an OS that can't run on those platforms is essentially useless right now. Requiring specialized hardware is a big con.

[Beherit]

Am I the only one here finding it a wee bit amusing that a GNU project is incorporating code from what is using a BSD license?

Once Richard Stallman finds out, he's gonna get his tits in a twanger.

[sinepgib]

Am I the only one here finding it a wee bit amusing that a GNU project is incorporating code from what is using a BSD license?

Once Richard Stallman finds out, he's gonna get his tits in a twanger.

Yes, I forgot to ask, but anyone knows why NetBSD was chosen? Are its drivers simpler or is it a microkernel? Or maybe is it because they can relicense derivatives, while Linux is GPLv2 only (so not "upgradable" to GPLv3)?

[coder]

Am I the only one here finding it a wee bit amusing that a GNU project is incorporating code from what is using a BSD license?

That's what I thought, but the article quotes:

The ACPI management, PCI management, and actual driver are in separate processes with RPC interfaces between them, which separates out their debugging, licencing concerns and execution.

[kylew77]

Yes, I forgot to ask, but anyone knows why NetBSD was chosen? Are its drivers simpler or is it a microkernel? Or maybe is it because they can relicense derivatives, while Linux is GPLv2 only (so not "upgradable" to GPLv3)?

I don't know for sure but NetBSD is the most portable of the *BSDs so its code is most modular being able to run on multiple architectures and is a research project at that so code is kept simple to understand I assume making it simpler to port over. OpenBSD is also portable but less so and optimizes for security so is less simple to understand, BUT the project focuses on code simplicity at the same time. FreeBSD is optimized for speed and supports very few architectures compared to the other *BSDs. What is curious is why DragonFlyBSD wasn't chosen since it is already a hybrid kernel (I used to mistakenly think DragonFlyBSD used a microkernel but was corrected), perhaps the reason DragonFly wasn't chosen was it only supports AMD64 and HURD doesn't yet fully support AMD64 but i686 instead.

[Ironmask]

At this point HURD is about as likely to succeed as the resurgence of Amiga. E.g. most people involved are dealing with necrophilia more than anything else.

Now, don't get me wrong, the Microkernel push has it's place, it's just that HURD is going nowhere and this will keep being true for as long as HURD insists on it's original goals (being **THE** GNU kernel). I think HURD should refocus efforts and move to, say, RISC-V or OpenPower, possibly introduce a hardware scheduler and it's own hardware communications bus for IPC. At this stage it's probably less painful to do a ground up redesign using lessons learned from other Microkernel OSes, like HelenOS and L4. Or simply adopt a fork of those projects as the new GNU HURD path.

Of course, these days GNU as it was originally envisioned is pretty much dead anyways; some bits remain like glibc, bash and some shell utilities, the rest has been essentially superceded by Systemd, Xorg and Linux.

I don't care what people work on their free time, I'm mostly just curious why they don't contribute to literally any other OS.
If you want a microkernel, contribute to DragonFlyBSD (I know it's not a full microkernel but I'm pretty sure it's aiming to be one).
If you want a GPL'd OS that challenges modern monopolies, contribute to ReactOS (NT is a good-enough hybrid architecture anyway).
The HURD, as you said, is completely dead. I understand contributing for purely hobbyist reasons, but if you actually care about your time or what you could be accomplishing with it, this is about as productive as rolling a hoop with a stick.

[novideo]

Am I the only one here finding it a wee bit amusing that a GNU project is incorporating code from what is using a BSD license?

Once Richard Stallman finds out, he's gonna get his tits in a twanger.

Most Linux drivers are BSD or MIT licensed too

Yes, I forgot to ask, but anyone knows why NetBSD was chosen? Are its drivers simpler or is it a microkernel? Or maybe is it because they can relicense derivatives, while Linux is GPLv2 only (so not "upgradable" to GPLv3)?

From https://www.gnu.org/software/hurd/co...glue_code.html

The most promising approach for getting newer drivers seems to be the ?Rump Kernel: it already does the hard work of providing an environment where the foreign drivers can run, and offers the additional benefit of being externally maintained. Rump also offers the necessary facilities for running all drivers in separate userspace processes, which is more desirable than drivers running in the microkernel.

[pabloski]

I don't know for sure but NetBSD is the most portable of the *BSDs so its code is most modular

Yes, but the reason why he is using NetBSD, is because of rump kernels. Is makes porting drivers relatively easy and has various other benefits. Also it runs the drivers in user-land processes, and this is the only way to run drivers on a microkernel.

Porting drivers from, say Linux, would be a huge effort.