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 Erich Focht wrote: > 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 ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
