Re: Hardware detection projects
Wichert Akkerman wrote:
>
> Previously Dan Shearer wrote:
> > My company has been asked to undertake some work involving building a
> > reliable hardware detection library for Intel Linux. There are quite a few
> > of these around, and several of them have links to people in the Debian
> > project, or appear to do so anyway. I looked for an appropriate list on
> > the Debian web pages but couldn't find one.
> >
> > So, perhaps you can advise me:
> >
> > 1) We want to build on existing code as much as possible (no question
> > of IP hassles, this clearly has to be GPLd.) Has Debian adopted
> > any particular library for this? Who would know about it?
>
> Not yet as far as I know. I think it is planned as part of the woody
> boot-floppies, but I haven't heard of anyone working on this so far.
>
Dan Helfman has had deb's of libdetect and lothar available, there is a
link to his debs from the debian sponsorship page.
http://www.internatif.org/bortzmeyer/debian/sponsor/
The packages are at http://torsion.org/witten/debian/ The packages wont
be officially in debian until an official member of debian adopts them
or Dan becomes an official debian member.
> > 3) There is the question of what to do next once the hardware has been
> > detected. What is the best group for discussing the Debian
> > installer, and interfaces for libraries that it uses etc?
>
> Definitely boot-floppies. I've cc'ed them on this response as well
> so they can pick this up.
>
Rumor has it that the next generation of boot floppies (which wont
really start until after potato is stable AFAIK) will use debconf as
much as possible for the install process, so hardware will be configured
by a package that relates to it.
I personally think as far as detection methods go it is far better to
have a standalone detection program than rely on kernel detection, for a
few reasons.
1) kernel size.
The boot kernel could be really small, with only drivers for the
distribution medium (e.g. cd) and the root partition medium (e.g.
ramdisk).
2) not tied to any particular kernel
Once hardware is detected a newer, fuller, more apropriate kernel can
be selected, fetched from the distribution medium and installed to the
target medium. (whose driver module can also be fetched from the
distribution medium)
3) installer managament
I beleive having an installer independent of the required kernel also
makes managemnt of the installer easier, as new releases will be
required only when the standalone detection progrma is changed (or other
reasons of course) rather than everytimne a new kernel is released.
This give the installer team more control.
4) Autodetected custom built kernel
From a general usage point of view, for linux users that compile their
own kernel, a hardware detection program based on whats in the kernel is
no use to them, as its a process thay need to do manually before they
can compile there kernel.
Conversly, it probably wouldnt be very difficult for a standalone
hardware detection program to generate a kernel .config file and
actually generate a customised kernel for the users hardware. This could
be a very good thing for users who dont know how to do it manually, e.g.
customising there kernel for there detected cpu rather than using a
kernel based on i386 becasue thats the lowest common denominator.
Hardware detection should be a bit easier with 2.3/2.4 with isapnp in
the kenrel.
I am a big fan of debian, however, i think that the Linux community in
general would be better off with the project being independent of any
distribution, as i think some previous efforts have beecome fragmented
based on what distro you use. It could work out well having the project
sponsored by linuxcare.
I would be interested in assisting you with your project.
Thanks
Glenn
Reply to: