Date: Mon, 21 Aug 1995 19:04:09 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: dufault@hda.com (Peter Dufault) Cc: joerg_wunsch@uriah.heep.sax.de, scsi@freebsd.org Subject: Re: scsiconf change Message-ID: <199508211704.TAA06324@uriah.heep.sax.de> In-Reply-To: <199508211334.JAA07241@hda.com> from "Peter Dufault" at Aug 21, 95 09:34:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
As Peter Dufault wrote: > > [I'm widening the audience a bit so we can get some more feedback, Joerg] (I've just subscribed to the scsi list, too. Should get mails from there within a few hours.) > [Joerg] > > Perhaps i've overlooked this? > > No, you haven't overlooked it. Apparently it either never worked the > way I thought it did or it was broken at some time. Note that we have > a type to use in the "scsidevs" structure (the matching structure), > and we carefully take the type out of that structure after a match: > > > *type_p = bestmatch->type; > > But this is a NOP since the match fails when the type is different. Yup. > I think that the current matching tests are wrong; it is too inflexible. Ideally, i would like that disk od0 at scbus0 target 3 would force the device on scbus0 target3 to go to the `od' driver. I'm not sure if this might be a good idea, since some bozo could attach a tape drive to target 3, and the `od' driver would horribly fail. > I would keep NEW_SCSICONF (since that is all I've been running lately > and one of the two branches is getting musty) > and change scsi_selectdev to a scoring scheme: Guess i like it. > Commentary about hunting through "knowndevs": > > The changes I outline here should give you what you want, and I > think would be an improvement. However, instead of a single > structure we really should have a distributed structure where in > addition to a possible list of "knowndevs" in scsiconf.c we have > additional devices in each type driver (st.c, sd.c, etc) and a way > to add new ones via config and "boot -c". Then your current problem > would be near zero: you'd just config in a new "rogue". Hmmmmm. Interesting. It would require extending config(8) and UserConfig. I don't see problems for the former, but maybe the latter will become too much bloated then? Remember, kernel pages are not pageable, and UserConfig is totally useless wasted memory once the kernel is running. > Unfortunately I'm no longer running -current: I don't have a system > unimportant enough at the moment to do so! If you'd like I'll make these > changes, get them to compile and then let you do some testing. These > are pretty low risk changes. I can do it. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508211704.TAA06324>