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 On Saturday 17 February 2007 00:35, Bernard Li wrote: > 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 > > On 2/16/07, dann frazier <[EMAIL PROTECTED]> wrote: > > On Fri, Feb 16, 2007 at 07:07:06PM +0100, Erich Focht wrote: > > > On Friday 16 February 2007 18:55, dann frazier wrote: > > > > On Fri, Feb 16, 2007 at 05:40:31PM +0100, Erich Focht wrote: > > > > > 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
pci-automod
Description: application/shellscript
------------------------------------------------------------------------- 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 sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
