I know this is a bit off topic but is there anything to read about how to implement a microkernel? Like a real booting system for x86.
GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
21–30 of 66 posts
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#22I know this is a bit off topic but is there anything to read about how to implement a microkernel? Like a real booting system for x86.
Andrew Tannenbaum's Minix [1] was pretty much made for this purpose. The current version is no longer a "teaching OS", but there is a lot of documentation on earlier versions around, including the original 1987 book [2] that Tannenbaum wrote on operating systems (which comes with the Minix source code).
[1] https://en.wikipedia.org/wiki/MINIX
[2] https://en.m.wikipedia.org/wiki/Operating_Systems:_Design_an...
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#23Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#24It's kind of unbelievable that HURD is still going. It's been the butt of many a joke in the Unix world: our equivalent of Duke Nukem Forever, or Mordeth. I can't admire their release schedule, but you're got to admire their persistance. One day, it might just be ready...
Hopefully it will run Project Xanadu
https://en.wikipedia.org/wiki/Project_Xanadu
(check the start date and first working version)
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#25Earlier quoted context omitted.
Most device drivers are more or less independent of CPU architecture. A PCI card is going to be the same PCI card no matter whether it's running on x86, Power, RISC-V or anything else.
Fair point. However, there will never be AGP or IDE for it. In fact there is no hardware with PCI and RISC V and may never be. My point is that they could solve the "what hardware do we support" problem by porting to architecture that doesn't have any hardware yet ;-) it would be gamble on an arch...
Once RISC-V matures, I'd be very surprised if no-one makes a board with PCIe slots, a SATA controller, a USB controller and all the other things which are relatively similar to a PC.
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#26Earlier quoted context omitted.
Fair point. However, there will never be AGP or IDE for it. In fact there is no hardware with PCI and RISC V and may never be. My point is that they could solve the "what hardware do we support" problem by porting to architecture that doesn't have any hardware yet ;-) it would be gamble on an arch...
Once RISC-V matures, I'd be very surprised if no-one makes a board with PCIe slots, a SATA controller, a USB controller and all the other things which are relatively similar to a PC.
In fact, one is already in progress (the U500): https://www.sifive.com/products/freedom/
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#27The changelog is so small... Can someone explain why do we need this? Why would we want to use it?
It's technically interesting and competition is never bad.
A fringe operating system can drive innovation by taking risks that a mainstream OS would never. Ultimately any improvements will appear on main stream operating systems so even if it's never used we're going to see some benefits.
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#28Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#29It's kind of unbelievable that HURD is still going. It's been the butt of many a joke in the Unix world: our equivalent of Duke Nukem Forever, or Mordeth. I can't admire their release schedule, but you're got to admire their persistance. One day, it might just be ready...
Unlike DNF it's not a commercial product, it relies on volunteers and corporate benefactors. For multiple reasons Linux got the brunt of OSS development resources behind it which wouldn't have helped Hurds schedule.
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#30Earlier quoted context omitted.
I never wrote a single driver, but I believe all bets are off with hardware. Drivers can execute logic on the cpu and on the chip, it's probably wild.
Drivers can execute code wherever they want in addition to the CPU but CPU will always be needed at some point.
Right; "drivers" that run only on a microcontroller in the device, don't touch the host's CPU, are called firmware. :)