Clarification of loadable drivers

[Jono Bacon]

Hi David,

> First, I think that installing drivers is really something you should be
> careful about e.g. personally I want .deb or .rpm from someone that I
> trust, e.g. my OS vendor or a 3rd party repository. And binary-only
> drivers, like for NVidia, is usually packaged into native packages these
> days so even this can be solved.

I suppose the benefit of doing it in a platform specific way and
therefore distribution specific way is that there is no issue with file
paths and other distro specific things. The problem with this way is
that there needs to be maintainers for every distro.

> Second, with enough automation a 3rd party package repository could
> automatically rebuild e.g. nvidia or ntfs kernel modules whenever the OS
> vendor releases a new kernel. So your update of the OS would be blocked
> until all your package dependencies are OK, e.g. you can't update to
> kernel-2.8.42-501 before kernel-module-nvidia-99.54-2.8.42-501 is
> available. [1] 

I think the problem that is faced here is regarding how this network
centric driver updates system hooks into Project Utopia. The natural
place for this seems to be .fdi files. I suppose what could work is that
the .fdi file contains the name of the driver (e.g. ov511 for a webcam),
and then Project Utopia could determine which distro the user is on and
where to locate the desired binary. If this could work within the remit
of the packaging system, there would be a big win.

I am just concious that .fdi files should not contain driver info for
each distribution. We don't want .fdi tags for specific Debian, RedHat,
Fedora, Gentoo packages. The key would be storing the name of the driver
in the .fdi file and then ensuring that the packaging system has the
logic to find the driver for the current working kernel.

Another thing to bear in mind would be people such as myself who use
generic kernel source form kernel.org. I am sure this could be worked
into the system too.

> Sure, it's a pain for hardware vendors with closed drivers to fight the
> changing ABI (and ABI stability does come a price). I, for a multitude
> of reasons, wouldn't like to encourage hardware vendors to distribute
> drivers outside the kernel source code. 

I am in two minds about this. In one way I am happy for GPLed binaries
to be distributed due to the technical complexity of handling drivers
with Linux, but in another way I like the transparency of source code
within the kernel. The other issue is that as the kernel grows, the
amount of driver code is going to get huge. How big will the kernel be
in 10 years?

My discussions about the ABI were mainly to find out if there was a
specific reason to break ABI compliance other than to stop the use of
binary modules.

Whatever the outcome of the software, I think with the right design this
could mark a tremendous leap in ease of device handling when combined
with HAL, GNOME-Volume-Manager, IVMan and all the other good work going
on. :)

	Jono

-- 
Jono Bacon - http://www.jonobacon.org/
Writer / Journalist / Consultant / Developer


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal