From: Josh Hansen <joshhansen@byu.edu>
To: linux-kernel@vger.kernel.org
Subject: Ease of hardware configuration
Date: Mon, 29 Oct 2001 17:27:34 -0600 [thread overview]
Message-ID: <01KA2VPVO4QI9JEBL9@EMAIL1.BYU.EDU> (raw)
Hello,
Perhaps I'm beating a dead horse with this, but my belief is that the feature
of greatest benefit to "Joe User" would be simplified hardware
installation/configuration. A user coming from Windows who is used to being
able to plug in a scanner, a mouse, a video card, whatever and having the OS
tell him what it is and automatically set up drivers for him will have real
trouble coming to Linux and having to compile a new kernel or new kernel
module for a new piece of hardware.
I am not familiar with the innards of the Linux Kernel, but here is my
"vision" of what could be done to change this. The kernel already is able to
detect what hardware is attached to the system's different buses generally
speaking, so the next step is for it to identify which hardware already has
drivers installed for it (built into the kernel or loaded modules). If no
drivers are installed, a kernel message to the effect of "New Hardware
Detected" could be issued. That is all the kernel has to do. The next steps
are handled in userspace software.
Some sort of daemon or cronjob mechanism can then monitor kernel messages
until it finds the "New Hardware Detected" message. Then, a generic
configuration utility is launched along with an appropriate frontend (simple,
ncurses, GTK+, KDE, Motif, Tcl/Tk, whatever...) to allow the user to
configure the device.
Now here comes the radical part (ok, so all of this is somewhat radical): the
configuration utility connects to a server such as linuxdevicedrivers.org or
some other slick domain name and downloads the appropriate kernel module
binaries for the hardware based on kernel version number and architecture
(example: nVidia GeForce module for kernel 2.4.13 on i386, or USB Scanner
module for kernel 2.4.4 on PowerPC). Once the module is obtained, it is
loaded into the kernel (with explicit IO/IRQ parameters for older hardware if
necessary).
Once the module is loaded, the utility quits.
The configuration utility could also allow for loading of modules from floppy
disk or any other filesystem, or from another internet server.
A working name for this utility and kernel message system could be "Linux
Kernel Device Configurator".
I expect that there will be many technical or other objections to such a
system. I also expect to get ripped apart by at least a few hackers out
there. However, that's great! I want input. I think this or a similar
mechanism could really increase the ease of use for the "average user" and
his nephew's godmother's granddaughter's roommate's dog, etc., etc.
Thank you!
- Josh Hansen
next reply other threads:[~2001-10-29 23:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-29 23:27 Josh Hansen [this message]
2001-10-30 2:27 ` Rob Landley
2001-10-30 9:19 ` Alan Cox
2001-10-30 4:38 ` Greg KH
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=01KA2VPVO4QI9JEBL9@EMAIL1.BYU.EDU \
--to=joshhansen@byu.edu \
--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
all inboxes | Powered by JetHome®