best way to determine devices with drivers

[Zenaan Harkness]

On Thu, 2004-06-24 at 20:14, Jono Bacon wrote:
> David Zeuthen wrote:
> > One possibility is to do what the Discover suite from Progeny does,
> > http://platform.progeny.com/discover/, e.g. have HAL expose global
> > properties like
> > 
> >  kernel.name
> >  kernel.version
> >  xorg.version
> >  ...
> > 
> > so you have .fdi files looking like this
> > 
> > <deviceinfo version="0.2">
> >   <device>
> >     <match key="info.bus" string="usb">
> >       <match key="usb.vendor_id" int="0x05dc">
> >         <match key="usb.product_id" int="0x0002">
> >           <merge key="storage.drive_type" type="string">compact_flash</merge>
> > 
> >           <if global="kernel.name" string="linux">
> >             <if global="kernel.version" range="[0;2.6.42[">
> >               <merge key="conf.driver" type="string">usb-storage</merge>
> >             </if>
> >             <if global="kernel.version" range="[2.6.42;inf[">
> >               <merge key="conf.driver" type="string">lexar-usb-storage</merge>
> >             </if>
> >           </if>
> > 
> >           <if global="kernel.name" string="freebsd">
> >             <if global="kernel.version" range="0;4">
> >               <merge key="conf.driver" type="string">some-freebsd-driver</merge>
> >             </if>
> >             <if global="kernel.version" range="5;inf">
> >               <merge key="conf.driver" type="string">a-newer-freebsd-driver</merge>
> >             </if>
> >           </if>
> > 
> >         </match>
> >       </match>
> >     </match>
> >   </device>
> > </deviceinfo>
> > 
> > and I'm sure someone can come up with a better XML format :-)
> 
> This would solve the issue of identifying kernel versions required for a 
> device. I suppose if this is built into the system for automatically 
> generating FDI files this will be a none-issue.

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.

> > And you want to make this very configurable and integrate with the
> > native package manager since I bet that distributions wouldn't like to
> > ship software that install software that is not packaged. 
> 
> Is packing really that important? If all that is being tranferred is a 
> single kernel module I don't really see the need to rely on the package 
> manager. So long as the kernel knows about the module, why would the 
> package manager need to know?
> 
> The other option is to allow the program that gets the module to check 
> if there is a module repository for the distribution first and then 
> maybe fall back on a generic respository second. Again, I see little 
> point in this as the kernel is one of the few approximate unified 
> elements of a distribution.

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.

> > This implies all sort of fun details like naming convention, e.g. what
> > is the name of the RPM or DEB with the NTFS driver. Also, if I'm
> > running Fedora I can get the NTFS driver only if I've configured a 3rd
> > party non-US repository. 
> 
> Exactly. I think if this can be done is a distribution agnostic way and 
> as such package agnostic way, this could prevent the issues. There are 
> course other issues. Do all kernels store modules in the same directory 
> or do some distros pervert this?

Can't answer the latter, but Debian prides itself on having
distro-internal consistency. And as a user of Debian, that's one of the
things that keeps me there - the package quality (of which consistency
is a big user-visible "quality" aspect).

> > I'm not sure what the answer to all your questions are, but it seems
> > to me this is very related to the hardware database proposed just last
> > week. 

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.

> > But my guess is that you'll need tight integration with distributions
> > and OS vendors to make this happen.

Kind of correct - the distros are responsible for their own internal
consistency, and will remain so.

Of course it behooves us to stick to standard locations and such of
course. But it's not for us to worry that there'll always be some
distros doing things Their Own Way (TM).

> > I'm not sure compiling drivers on
> > the fly is the way to go, I think packages sounds like a better idea,
> > but I could be wrong.
> 
> I think we need to identify the range of the playing field first; how 
> many things vary among distributions and kernels. With this in mind a 
> better judgement can be made to make this a reality. I think that if a 
> packaging route is taken, distribution co-operation will be required. 
> Irrespective of whether packaging is used at all, we will still need 
> maintainers for different modules.

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 guess it's a lot more complex really - there's the entire free
> > software angle to consider like the fact that some people argue that
> > kernel modules should all be GPL and in the kernel tree etc. etc. But
> > I'm not going to start that thread :-)
> 
> I agree, but if this is a limitation, it will kill the project. If 

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?" :)

> people are really concerned about getting source and compiling it 
> themselves, they will have the knowledge to go and compile the code 
> anyway.

That's not the issue. The problem people are having (and at this very
point in time on debian-devel) is grappling with non-free-ness of
firmware - firmware that's included in the Linux kernel upstream, and
whether to classify it as software or data (getting pretty stupid there
in my high opinion :) - and therefore how it can be distributed (or
not).

Non-free drivers are a much simpler case - either the license
(/software) is libre software or its not.

>  I would say this project is aimed the less-technical user who 
> has no clue about compiling kernels.

Of course. And those users will use a distro in the first place. And our
work is of its very nature pretty technical - just so that we can make
it easy for the Aunt Tillys of the world.

If we stick to the principles we'll be packaged up in no time by the
distros because It Works:
 - auto device detection
 - plug and play - adding and removing is seamless
 - "good" GUI principles (icons matching the device, as above)

> > I really agree this is important. It could be interesting to work out
> > some of the usecases all the way from the metal through the kernel and
> > to the desktop to get an overview what is really needed.
> 
> Agreed.

Double agreed.

BTW, we-the-hwdb project have a schema for the CHFD underway. I'll keep
this list informed of progress.

cheers
zen

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