best way to determine devices with drivers

[Jono Bacon]

Zenaan Harkness wrote:

>That is indeed the plan with the Community Hardware Freedom DB (if you
>think of a better/ shorter, non-ambiguous name, please post). And if the
>XML format changes (gasp! :) it'll be a perl (or sed|pick your language)
>script away.
>
>  
>
I would call it the Open Software Hardware Database. :)

How will the XML format change? Isn't this the XML format in FDI files 
or do you have your own XML format?

>In Debian for example, I think that all kernel-modules will be a part of
>package kernel-modules-2.XXX.
>
>If there really are "fully" cross-kernel-version modules in hal
>(certainly wouldn't be cross-arch), then the hal modules might go in a
>separate package, eg hal-kernel-modules-2.XXX, or just in the primary
>hal package.
>
>I personally can't see that happening though. I imagine they'll just be
>kernel modules like all other kernel modules, and get installed into
>/lib/modules/kernel-VERSION like all other kernel modules.
>  
>
Sorry, I am a little confused here. What do you mean by 'modules in 
hal'? Are we not just talking about stock kernel modules?

One idea that I had was based around the way the debian build system 
works. It could be useful if someone could upload the source for a 
kernel version and the server will compile the kernel, make the modules 
available as downloadable pieces in response to hal/other software that 
identifies a device and attempts to download the driver. This build 
process could also take distro specific patches and generate relavent 
modules there.

The benefit of this system is that the entire process is automated.

>I think you're right. At least, there's a lot that it makes sense for us
>to provide to hal. [device, kernel, module, distro] mappings is one we
>will be providing.
>  
>
It does seem like the project is basically automating the process of FDI 
file creation, and working alongside other projects to provide automatic 
driver installation. Maybe you should work closely with Andrew to ensure 
there is no cross-over and duplication of work.

>Anything that should be in the kernel, should be in the kernel proper.
>It doesn't feel right to me to be taking kernel modules out of the
>kernel-project.
>
>Distros (downstream, eg Debian) package upstream software (eg. hal) to
>their own specifications. We do not have to worry about this, and we
>assume it will happen.
>
>As to variances between distros: we stick to FHS etc for our own
>purposes - if the distros deviate from this, it is up to their packagers
>to modify hal installation to suit their needs.
>
>As to variances between kernels: this is just another reason we should
>aim for all kernel modules to be part of the Linux kernel tree. Ie.
>in-kernel proper. Anything else feels a little odd to me, and you don't
>get the public review/ kernel team maintenance support, "many eyeballs
>making all bugs shallow", etc. We should stick to the program, and the
>existing program (proscription) evidently works well, right :)
>  
>
I think the importance is in reducing the maintenance of those who look 
after the modules. This process should preferably be automated by build 
systems. I agree that this system should stick to the FHS and stick to a 
stock kernel. If people wish to provide and maintain additional modules 
(such as companies provding their modules for their products), then this 
should be available if they can provide the time to maintain the modules 
and their distribution. When I say maintain by the way, I mean maintain 
the build process, not neccessarily maintain the code for the module. 
The the most part, the kernel tree can be automated though.

>I think the most important thing to 'satisfy' the license bigots is to
>simply document the licensing of each part of the software. Make sure
>you tell people what they're up for, then distros can determine what
>fits in with their world view. Eg. Debian would put all non- non-free
>depending software into its 'main' archive, all free software with
>non-free dependencies into its 'contrib' archive, and all non-free
>software into its non-free archive.
>
>Just be up front about what we have today, what we are distributing as
>upstream, and that's the best we can do for the distros.
>
>(I myself will not putting any effort into software-without-freedoms,
>but hey, you've got your own choice right - "Where will you compute in
>freedom today?" :)
>  
>
Yeah. There could be a setting to warn users of non-free software. This 
would lock out NVidia binary drivers for example. For those who do want 
to use non-free drivers, this should be an option too - particularly if 
companies come on board to provide their own drivers.

Keep us updates with your progress Zen. :)

    Jono

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


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