GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
1–10 of 66 posts
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#2Do a RISC V port so hardware can be supported as it becomes available. No more need to play catch-up with drivers.
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#3Do a RISC V port so hardware can be supported as it becomes available. No more need to play catch-up with drivers.
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.
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#4The changelog is so small... Can someone explain why do we need this? Why would we want to use it?
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#5Do a RISC V port so hardware can be supported as it becomes available. No more need to play catch-up with drivers.
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.
Device drivers don't execute on the device. They execute on the CPU, instructing the OS how to use the device. So device drivers do need to support both the CPU architecture and the OS platform.
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#6Do a RISC V port so hardware can be supported as it becomes available. No more need to play catch-up with drivers.
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...
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#7Earlier 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.
Device drivers don't execute on the device. They execute on the CPU, instructing the OS how to use the device. So device drivers do need to support both the CPU architecture and the OS platform.
Not when they are open source...
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#8Earlier 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.
Device drivers don't execute on the device. They execute on the CPU, instructing the OS how to use the device. So device drivers do need to support both the CPU architecture and the OS platform.
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.
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#9Earlier 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...
Do modern motherboards even still ship with AGP and IDE? I thought those were on a death march almost a decade ago.
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#10Earlier quoted context omitted.
Device drivers don't execute on the device. They execute on the CPU, instructing the OS how to use the device. So device drivers do need to support both the CPU architecture and the OS platform.
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.