public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris White <chriswhite@gentoo.org>
To: linux-kernel@vger.kernel.org
Subject: Kernel Driver Automation
Date: Wed, 16 Feb 2005 04:05:47 +0900	[thread overview]
Message-ID: <1108494347.7811.9.camel@secures> (raw)

[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]

Hi, My question was regarding automation of the driver compile process
in the kernel.

Basically, as it is, I have seen lots of people scared half to death of
linux because of one of its most powerful features: the kernel.  Windows
users are so used to "Insert device, windows sees device, windows finds
driver, windows installs driver, reboot and pray driver works ;)".  The
kernel, however (not in all cases mind you), is full of lots of
searching around for the right driver, making sure the right SCSI/IDE
controller is selected for DMA, and getting the network setup.
Ironically, if the network card driver is not working, there's no way to
google around for information on what modules to compile in for various
drivers.

Now then.. on to the real stuff.  Basically it comes down to the
question of what the kernel does so far as to have capabilities in
interfacing with a userspace application that would analyze the hardware
and attribute the proper driver for it.  I've seen techinques such as
compiling all modules and loading until one finally works.  This is
somewhat effective.. but in the long run leaves a lot of kernel bloat.
There are also wizards out there during distro install phase that help
with the process.  Is there any other technique as far as attributing
hardware to driver?  Something like the way USB can attribute a driver
to a product by the id and vendor?

The basic idea would be to have a userspace program that would be run
before the kernel compile process and check the device identification
string (using /proc?) and match it up against the correct module.  This
would, I'm guessing, require that modules would have an array containing
the appropriate device string that it works with, enabling the userspace
application to match the two up and generate the proper configure
option.  Though another propblem I ran into is "You need this module
compiled for this module to work".  Maybe there's some sort of module
dependancy information I'm not aware of.

Let me know if any of this makes sense or if I need to redirect my ideas
to something more realistic.  Thanks ahead of time for the
responses/criticism/flames.

-- 
Chris White <chriswhite@gentoo.org>
------------------------
Sound   | Video   | PPC
ChrisWhite @ irc.freenode.net

[-- Attachment #2: このメッセージにはデジタル署名された部分があります --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

             reply	other threads:[~2005-02-15 19:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-15 19:05 Chris White [this message]
     [not found] <mailman.1108494546.30588.linux-kernel2news@redhat.com>
2005-02-16 21:59 ` Kernel Driver Automation Pete Zaitcev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1108494347.7811.9.camel@secures \
    --to=chriswhite@gentoo.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox