hardware management system
Hello,
I think something Debian (potato) doesn't have is a 'hardware
management system' or hardware detection. Most other distros introduces
something like that in their latest releases. I think this is an important
factor as linux is becoming more and more famous also for those people who
do not before installing new hardware figuring out which parameter to set
for module. On the other hand "advanced" linux users do not want a
automatic hardware installation as they think it is better to do it by hand.
In short I want to say, that Debian should have a hardware management system
that should be able to use by both groups of users. As far as I saw most
distributions with a hardware detection only mentioned the beginner's part.
I've got some ideas how this could be implemented and I'd also like to try
realising this project.
It should be based on two databases which can be accessed by frontends. One
database is responsible for all known hardware to the system, the other for
the hardware that is currently available in the computer. There are always
several ways for records in and out using tools that are based on the
frontends. So it is flexible.
I've taken some notes about how to do it:
* all known hardware (db)
the hardware db should not be a package that you can update by installing
a new version, but there should be a package with most known hardware
that is imported into the master hardware-db (in /var). So you are able to
generate and update your hardware db from many different sources like e.g.
the default package I mentioned or a server on the web. This should be done
each by an own tool. So it is possible only to install the tools for the
dbs one need. Also it'd be nice if there was option only to update a
particular hardware section like e.g. soundcards.
- frontend to add hardware in the db in a common format
- several other frontends that use that master add frontend and add
hardware, e.g. from converting /usr/share/misc/pci.ids, RedHat's
kruzu, a database server in the web that has records for new hardware
given by users.
- frontend to get the db records
- frontends/libaries for several languages like shell, C, etc. that are
based on the the master-get frontend
* hardware available in the system (db)
- master tool to update the db regularly, e.g. in an init.d script by
using several other tools detecting hardware in a common format e.g.
via a perl interface or a shell interface (implemented in perl) that
can be used by several other languages, too.
- pci-devices
- printers
- ddc (monitor)
- etc.
- master tool that notices changes in hardware db's and invokes the
corresponding tool for that type of hardware. The tools can access
the db records of their section(s) via a perl or shell (or another)
interface.
- isdn configuration tool
- X or framebuffer configuration tool
- sound configuration tool
- etc.
- corresponding to the global level of decisions the user want to take that
is set, the frontends do activities from doing everything automatically to
only informing the user about new hardware.
- each frontend can get the global configuration from the master frontend,
but the records of available or knows devices from the corresponding
frondend for the dbs.
- the tools for detecting hardware or installing hardware should be own
packages which give notice to the dbs'-tools that they are availible,
e.g. by a file with the specifications in a particular directory from the
hardware management system. Then they are invoked by the corresponding
tools. This garuantees flexibility.
+---------------------------+
| master tool |
+---------------------------+
|
|
+-----------+ | +-----------+
| db of all | | | db of |
| known | | | available |
| devices | | | devices |
+-----------+ | +-----------+
/\ || | /\ ||
|| \/ | || \/
+-------------+ +--------------+ | +------------+ +---------------+
| hardware in | | hardware get | | | get avail. | | update avail. |
+-------------+ +--------------+ | +------------+ +---------------+
^ | | | ^
+-------------+ | | checks if db of | | +-------------+
| standard-db |--+ +-> availible or known <-+ +--| pci-devices |
+-------------+ | devices changed | +-------------+
| pciutils-db |--+ | +--| printers |
+-------------+ | | | +-------------+
| web-db |--+ invokes the corresponding tools +--| isapnp |
+-------------+ | | | +-------------+
| redhat's db |--+ +--------------+--------------+ +--| etc |
+-------------+ | | | | | | | +-------------+
| etc |--+ isdn sound ethernet video scsi ide
+-------------+
The format of the dbs could be done simelar to debconf's in
/var/lib/debconf/*.db. In both you'd need several field which differ from
the type of the device, e.g. you don't need the same fields for a printer
and a soundcard. Also the bus (or whatever you want to call it: pci, isapnp,
lp, etc.) and the type of hardware should be specified. Depended on this two
field the master tool decides which frontend to invoke. If there are several
frontends for the same type of hardware, dependend on the level of decisions
the user want to take either the one which claims to be most stable is taken
or the user will be prompted.
I think I'd be nice that for user interaction the frontends could use debconf.
Greetings, Roland
--
Roland Bauerschmidt -- Freiberger Str. 17, 28215 Bremen, Germany
phone: +49 421 3762382, e-mail: rolbau@gmx.de, http://roland.inbremen.net/
Debian GNU / Linux -- the choice of the GNU generation
Reply to: