> We just had an interesting argument about this one on irc. I think the > outcome was that we couldn't rely on this because windoze detect is > somewhat broken. I disagree because you would almost certainly have > corrected windoze' opinions about your hardware if they were wrong. In > any event, it should not be done as step 0. why's that? the idea is that if, after this phase, we've picked up all the hardware, then there's no point in proceeding with the rest of the stuff (which may hang) > machines. If I'm right about that (please someone correct me if I'm not) > then detecting the ISA bus is pretty easy: if the machine is PCI look > for the ISA bridge. If it's not PCI, is it an i386? i would think we have much more reliable ways of telling whether a machine is i386? > As noted above, legacy hardware owners PROBABLY know what they have. If > they don't, well they should. => Of course what is crossing my mind > right now is legacy 486 freebees. These usually don't come with > manualrs. There's no way without the manuals to know what is built on to > the board, usually this includes legacy video, I/O, sometimes sound, > occasionally an addon modem.[1] Since step 3 is the most dangerous, we should probably do something like this: do step 0, and show what we have. stop if nothing else needs to be detected. if user wants to continue, do steps 1 and 2, then again stop and ask if user wants to continue. then do step 3. in the spirit of configurability, all this should be optional, of course. > At this time SCSI/IDE drivers must be compiled in. I'd like this to > change though. It should be possible to append a driver to the kernel's > image file, possibly update info in the kernel image (similar to what > rdev does) and have the modules attached to the kernel in this manner to > be loaded on startup. what do you mean by this? are you just refering to the install disks? most certainly, if a user were to upgrade his system and want to run the detection process again, there's no reason to not detect scsi/atapi devices that might have been added. there's no reason why drivers for Zip drives and scsi/atapi cdroms shouldn't be loaded as modules. > This would be a Good Thing. You take a kernel image with just about > everything but the floppy driver (even that possibly) as modules. You do > the detection thing and figure out what modules _including_ IDE and SCSI > are needed. Anything that is needed to mount the root fs can just be > attached to the kernel and it'll be as if you compiled it in for all > intents and purposes of getting the machine running. as above, i was thinking more on the lines of peripheral hardware like zip drives and CD-ROMs. In a certain sense, harddisk drivers should be compiled in. > > All the while, we'll need to keep some type of a checkpoint log, maybe not > > writing to disk for each device, but do them in blocks. > Why not start by asking them what kinds of hardware they would like to > detect? Some types of cards are more likely break stuff looking for them > than others. I'd break it down into device category. Things that come > to mind are network cards, SCSI cards, serial/modems/input devices, > parallel devices, sound cards, .... that's a good idea too -- one thing though. Debian has a certain tendency to make things so configurable that it becomes confusing/difficult for a newcomer. it's good for things to be configurable but there must be a balance so it doesn't become overwhelming. > Something as yet unadressed, what do we do with the info once we have it. > I suppose we could dump the info we find in /etc/hwprobe/* or something > like that. Maybe /etc/hwprobe/cdroms would include how many cdroms the > probe found, data about each one, and the one that's considered the > "default".. I'd welcome other ideas or more thoughts about this idea. > I'm not sure it's the right way to do things but I'm also not sure it's > the wrong way either. that's what i was thinking too.. then all our config tools can use the info in there. randolph -- Debian Developer <tausq@debian.org> http://www.TauSq.org/
Attachment:
pgpkoy3Sz6x3H.pgp
Description: PGP signature