Re: Bug#139945: ITP: prokyon3 -- a multithreaded MP3 manager and tag editor for Linux.
On Wed, Mar 27, 2002 at 04:10:21PM -0500, Stephen Ryan wrote:
> The Hurd is a cutting edge research
> project.
>
The Hurd is not a research project really. What we are implementing is
pretty well known for years in operating system research.
> I think it is clear that one major job (perhaps *the* major job) of an
> operating system kernel is to manage access to hardware resources;
Yes, it is one of the jobs. And your criticism is correct.
> The Hurd faces an uphill battle, in that there is already a fairly good
> kernel available under the GPL, and it is improving at a very rapid
> rate.
This interpretation is, especially with regards to device drivers,
incorrect. We are facing an uphill battle because there is a fairly bad
kernel available where all device driver development is done. The Linux
kernel device driver framework (as much as it exists) is a bad joke. It
hinders code reuse to the point that Linux can't reuse its own drivers
from version to version, they have to update all the code from major release
to release because they just don't get the internal interfaces right.
If the Linux developers had taken the time to build up a good device
driver framework, the Hurd and many other free software projects could
greatly benefit from it. We are already doing it. In GNU Mach 1.x, we
are using the Linux 2.0 block device, SCSI controller and NIC driver
code. That is all that could be ripped with a reasonable effort. We
are stuck with the 2.0.x versions because of the incompatibilities
between 2.0 and 2.2+. In GNU Mach 2.x, we will use OSKit, which is a
driver framework developed for the Flux kernel, which uses BSD and Linux
drivers internally. So we can punt off the incompatibilities to the
OSKit project. They have wrapped block device, SCSI controller and NIC
driver from Linux, too, but they also had trouble wrapping any of the
other drivers. I just say one word: character devices. Look into any
Linux kernel and cry.
I have some hopes for L4Env, which will be a driver framework from
scratch, and hopefully will succeed. Then we might have a second free
software driver framework we can use.
You are misinformed if you think we don't support these devices because
we can't. It's not too hard to rip the Linux sound driver and drop it
in some of our kernels and get it to work. But there is simply no use
in doing this work if it leads to heavy modifications, so that driver
development is forked, and our external interfaces end up as broken as
the Linux interfaces are. We are not limited to ioctl interfaces to
control drivers, so we can do the right thing and develop proper
interfaces for the driver types.
So, we want a couple of things: We want broad device driver support, we don't
want to fork driver development, and we want good code reuse and clean
interfaces. The first two points suggest strongly using the Linux
drivers. The latter two points although make Linux drivers a bad
choice currently.
Do you see the dilemma? Solving this is not an easy task. If you want
to help, you are welcome. For the nearest future, wrapping more drivers
into OSKit is the most sensible choice. When interfaces are written and
glue code designed to a level where they hide all brokeness of actual
implementations, then you will see a sudden rush of increased device
support in the Hurd. From my point of view, all device driver
developers in Linux are also developing for the GNU/Hurd, even if they
don't realize it :) (The keyword here is cooperation. The Hurd, as an
integral part of the GNU project, was always developed as part of GNU,
and thus a lot of effort also went not directly into the Hurd, but into
related projects like the GNU C library. Which interestingly now is
used by GNU/Linux, too. And today, nobody is using libc5 anymore).
> The bar has been raised, and it
> isn't going back down.
It really depends on your priorities. However, I won't bother you with
the areas where the Hurd beats Linux already. They probably don't
matter for you.
> It seems to me that making comments about the majority of Debian users
> just abandoning working systems
Well, that's Jeroen ;)
Thanks,
Marcus
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: