Discussion:
[Sisuite-devel] RFC: solution for dealing with unknown hardware
Erich Focht
2007-02-16 16:40:31 UTC
Permalink
Guys,

I'd like to include a tiny script (attached) into boel_binaries which can
solve one of our longest lasting problems: the inability to deal with unkown
hardware. Of course, we have UYOK, but that sometimes fails and is somewhat
unconfortable to use. No, I don't want to replace UYOK. I just believe that
the current detection framework can get some help.

pci-automod (the script in the attachment) detects the PCI hardware in your
machine and checks which module has support for this hardware. It deals with
three classes of hardware right now: storage, network and serial. It does not
require any pci.lst list, it only uses information available in the modules,
respectively the modules.pcilst file. I.e. if it finds a module which supports
your hardware, it will tell you or load it. The script is simple and runs fine
under the busybox "ash".

Usage:
pci-automod --class storage|net|serial --list|--load|--hwlist

Detect modules which need to be loaded in order to get the
storage or ethernet drivers activated. This uses information
in the modules and from the PCI bus. When multiple modules are
available for one device, all of them will be loaded!!!

Options:
--class storage|net|serial : device class filter
--list : list modules to load
--hwlist : produce hardware.lst compatible lines
for systemconfigurator
--load : try to modprobe the modules



Usage examples for systemimager:

pci-automod --load --class storage

will load the storage related drivers which the current detection framework
wasn't able to detect.

pci-automod --hwlist --class storage --class net >> /a/etc/systemconfig/hardware.lst

will add the detected storage and network related modules to the hardware.lst
file in the freshly deployed node such that systemconfigurator has an easy job
to configure modprobe.conf and the initrd.


There is a small drawback: if there is more than one driver available for
supporting particular hardware, this script will list and try to load all
these modules. How should we deal with this situation? Should we select only
the first available module? Or add some detection for stuff that already has a
driver in kernel (or module) and just skip that load? This would lead to only
the first driver being loaded.

The inclusion of this thing is straight forward and requires additional lines
in the systemimager trunk. Should I include it? Any comments or ideas?

Thanks,
best regards,
Erich
dann frazier
2007-02-16 17:55:18 UTC
Permalink
Post by Erich Focht
Guys,
I'd like to include a tiny script (attached) into boel_binaries which can
solve one of our longest lasting problems: the inability to deal with unkown
hardware. Of course, we have UYOK, but that sometimes fails and is somewhat
unconfortable to use. No, I don't want to replace UYOK. I just believe that
the current detection framework can get some help.
pci-automod (the script in the attachment) detects the PCI hardware in your
machine and checks which module has support for this hardware. It deals with
three classes of hardware right now: storage, network and serial. It does not
require any pci.lst list, it only uses information available in the modules,
respectively the modules.pcilst file. I.e. if it finds a module which supports
your hardware, it will tell you or load it. The script is simple and runs fine
under the busybox "ash".
doesn't udev do this already?
--
dann frazier
Erich Focht
2007-02-16 18:07:06 UTC
Permalink
Post by dann frazier
Post by Erich Focht
Guys,
I'd like to include a tiny script (attached) into boel_binaries which can
solve one of our longest lasting problems: the inability to deal with unkown
hardware. Of course, we have UYOK, but that sometimes fails and is somewhat
unconfortable to use. No, I don't want to replace UYOK. I just believe that
the current detection framework can get some help.
pci-automod (the script in the attachment) detects the PCI hardware in your
machine and checks which module has support for this hardware. It deals with
three classes of hardware right now: storage, network and serial. It does not
require any pci.lst list, it only uses information available in the modules,
respectively the modules.pcilst file. I.e. if it finds a module which supports
your hardware, it will tell you or load it. The script is simple and runs fine
under the busybox "ash".
doesn't udev do this already?
Well, no. Not in systemimager. udevd is taking care of the /dev device files,
yes. But at the moment when it is started, the modules aren't actually
available. That means the udev events can't trigger loading any modules in
systemimager.

Currently a tool called "discover" is used for detecting hardware, and it uses
lists of supported vendor:device vs. modules. Managing this list is the pain
we all have when touching new hardware. The tiny script actually has the
potential to get rid of this list.

Regards,
Erich
dann frazier
2007-02-16 20:31:04 UTC
Permalink
Post by Erich Focht
Post by dann frazier
Post by Erich Focht
Guys,
I'd like to include a tiny script (attached) into boel_binaries which can
solve one of our longest lasting problems: the inability to deal with unkown
hardware. Of course, we have UYOK, but that sometimes fails and is somewhat
unconfortable to use. No, I don't want to replace UYOK. I just believe that
the current detection framework can get some help.
pci-automod (the script in the attachment) detects the PCI hardware in your
machine and checks which module has support for this hardware. It deals with
three classes of hardware right now: storage, network and serial. It does not
require any pci.lst list, it only uses information available in the modules,
respectively the modules.pcilst file. I.e. if it finds a module which supports
your hardware, it will tell you or load it. The script is simple and runs fine
under the busybox "ash".
doesn't udev do this already?
Well, no. Not in systemimager. udevd is taking care of the /dev device files,
yes. But at the moment when it is started, the modules aren't actually
available. That means the udev events can't trigger loading any modules in
systemimager.
udevtrigger can do this after the fact - this is what I believe both
Debian and Ubuntu are using.
--
dann frazier
Bernard Li
2007-02-16 23:35:46 UTC
Permalink
Hi all:

udev is "supposed" to replace discover however we haven't got to the
point where udev can fully replace it yet (I tried a while back,
installation will fail if I remove discover bits).

So I think if Erich's script can solve our problems in the interim
before we fully integrate SystemImager with udev, then perhaps we can
go with that. We are not planning to remove discover bits though,
right?

But as Andrea mentioned in another email, I guess we are trying to
freeze for 3.8.0 - so I am not sure whether this should go into 3.8.x
or 3.9.x.

Cheers,

Bernard
Post by dann frazier
Post by Erich Focht
Post by dann frazier
Post by Erich Focht
Guys,
I'd like to include a tiny script (attached) into boel_binaries which can
solve one of our longest lasting problems: the inability to deal with unkown
hardware. Of course, we have UYOK, but that sometimes fails and is somewhat
unconfortable to use. No, I don't want to replace UYOK. I just believe that
the current detection framework can get some help.
pci-automod (the script in the attachment) detects the PCI hardware in your
machine and checks which module has support for this hardware. It deals with
three classes of hardware right now: storage, network and serial. It does not
require any pci.lst list, it only uses information available in the modules,
respectively the modules.pcilst file. I.e. if it finds a module which supports
your hardware, it will tell you or load it. The script is simple and runs fine
under the busybox "ash".
doesn't udev do this already?
Well, no. Not in systemimager. udevd is taking care of the /dev device files,
yes. But at the moment when it is started, the modules aren't actually
available. That means the udev events can't trigger loading any modules in
systemimager.
udevtrigger can do this after the fact - this is what I believe both
Debian and Ubuntu are using.
--
dann frazier
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
sisuite-devel mailing list
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
Erich Focht
2007-02-17 00:14:19 UTC
Permalink
I also believe that integrating udevtrigger requires at least the amount of
changes as the tiny script, in addition to including the binary. I think udev
could handle USB devices as well, but don't particularly care about those,
actually. But the generation of hardware.lst requires some code, as well...

An updated version of the script is attached. It only loads the first module
which it encounters for a particular device, that is an improvement which
makes it safer than the first version. In fact I believe it could even replace
"discover" now, but that should be tested on complex setups. Therefore for now
(3.8.0) I'd suggest to just add this script and not remove discover. It really
eases life with new hardware, I checked it on two platforms which are unknown
to "discover" and could install and boot them with the systemimager
kernel. This is a significant improvement to the ever returning pains of
unknown hardware.

Regards,
Erich
Post by Bernard Li
udev is "supposed" to replace discover however we haven't got to the
point where udev can fully replace it yet (I tried a while back,
installation will fail if I remove discover bits).
So I think if Erich's script can solve our problems in the interim
before we fully integrate SystemImager with udev, then perhaps we can
go with that. We are not planning to remove discover bits though,
right?
But as Andrea mentioned in another email, I guess we are trying to
freeze for 3.8.0 - so I am not sure whether this should go into 3.8.x
or 3.9.x.
Cheers,
Bernard
Post by dann frazier
Post by Erich Focht
Post by dann frazier
Post by Erich Focht
Guys,
I'd like to include a tiny script (attached) into boel_binaries which can
solve one of our longest lasting problems: the inability to deal with unkown
hardware. Of course, we have UYOK, but that sometimes fails and is somewhat
unconfortable to use. No, I don't want to replace UYOK. I just believe that
the current detection framework can get some help.
pci-automod (the script in the attachment) detects the PCI hardware in your
machine and checks which module has support for this hardware. It deals with
three classes of hardware right now: storage, network and serial. It does not
require any pci.lst list, it only uses information available in the modules,
respectively the modules.pcilst file. I.e. if it finds a module which supports
your hardware, it will tell you or load it. The script is simple and runs fine
under the busybox "ash".
doesn't udev do this already?
Well, no. Not in systemimager. udevd is taking care of the /dev device files,
yes. But at the moment when it is started, the modules aren't actually
available. That means the udev events can't trigger loading any modules in
systemimager.
udevtrigger can do this after the fact - this is what I believe both
Debian and Ubuntu are using.
--
dann frazier
Andrea Righi
2007-02-18 11:38:17 UTC
Permalink
I agree with Erich, for 3.8.0 it should be better to continue to use the
well-tested discover+udev approach. Moreover remember that 2.4 kernels
will not work without discover, since they don't support udev and sysfs.
This means that if we want to support some old distributions, still used
in production, like RHEL3, SLES8, etc we can't totally replace discover
yet... but we could decide at runtime if it's correct to use an approach
or another depending on the running kernel. IMHO this solution needs
more than a simple script, so it could be dangerous to have this in 3.8.0.

If you agree the plan could be the following:
- now (within today) I open the 3.8.0 branch on svn
- in 3.8.0 we'll include only bugfixes and we'll try to update the
documentation (in particular the pdf manual... hey... it shouldn't be
too bad to have an updated offline documentation other than the wiki)
- in the trunk we try to integrate Erich's script (that will be used
only with 2.6 kernels)
- and maybe we could open also a "-udevtrigger" branch to do some
scouting with udevtrigger

What do you think?
-Andrea
Post by Erich Focht
I also believe that integrating udevtrigger requires at least the amount of
changes as the tiny script, in addition to including the binary. I think udev
could handle USB devices as well, but don't particularly care about those,
actually. But the generation of hardware.lst requires some code, as well...
An updated version of the script is attached. It only loads the first module
which it encounters for a particular device, that is an improvement which
makes it safer than the first version. In fact I believe it could even replace
"discover" now, but that should be tested on complex setups. Therefore for now
(3.8.0) I'd suggest to just add this script and not remove discover. It really
eases life with new hardware, I checked it on two platforms which are unknown
to "discover" and could install and boot them with the systemimager
kernel. This is a significant improvement to the ever returning pains of
unknown hardware.
Regards,
Erich
Post by Bernard Li
udev is "supposed" to replace discover however we haven't got to the
point where udev can fully replace it yet (I tried a while back,
installation will fail if I remove discover bits).
So I think if Erich's script can solve our problems in the interim
before we fully integrate SystemImager with udev, then perhaps we can
go with that. We are not planning to remove discover bits though,
right?
But as Andrea mentioned in another email, I guess we are trying to
freeze for 3.8.0 - so I am not sure whether this should go into 3.8.x
or 3.9.x.
Cheers,
Bernard
Post by dann frazier
Post by Erich Focht
Post by dann frazier
Post by Erich Focht
Guys,
I'd like to include a tiny script (attached) into boel_binaries which can
solve one of our longest lasting problems: the inability to deal with unkown
hardware. Of course, we have UYOK, but that sometimes fails and is somewhat
unconfortable to use. No, I don't want to replace UYOK. I just believe that
the current detection framework can get some help.
pci-automod (the script in the attachment) detects the PCI hardware in your
machine and checks which module has support for this hardware. It deals with
three classes of hardware right now: storage, network and serial. It does not
require any pci.lst list, it only uses information available in the modules,
respectively the modules.pcilst file. I.e. if it finds a module which supports
your hardware, it will tell you or load it. The script is simple and runs fine
under the busybox "ash".
doesn't udev do this already?
Well, no. Not in systemimager. udevd is taking care of the /dev device files,
yes. But at the moment when it is started, the modules aren't actually
available. That means the udev events can't trigger loading any modules in
systemimager.
udevtrigger can do this after the fact - this is what I believe both
Debian and Ubuntu are using.
--
dann frazier
Continue reading on narkive:
Search results for '[Sisuite-devel] RFC: solution for dealing with unknown hardware' (Questions and Answers)
3
replies
Briefly describe the Microsoft's 2000 DNS management?
started 2006-08-17 22:05:37 UTC
computer networking
Loading...