Date: Mon, 21 Aug 1995 11:02:52 -0700 (PDT) From: Julian Elischer <julian@ref.tfs.com> To: joerg_wunsch@uriah.heep.sax.de Cc: dufault@hda.com, scsi@freebsd.org Subject: Re: scsiconf change Message-ID: <199508211802.LAA24139@ref.tfs.com> In-Reply-To: <199508211704.TAA06324@uriah.heep.sax.de> from "J Wunsch" at Aug 21, 95 07:04:09 pm
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.)
it's been very quiet.. you haven't missed much..
>
> > [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.
>
well it used to work at TFS, but it's changed almost beyond recognition.
I USED to have a device that reported itself as a tape when it was a processor..
I just added an entry in for it that said it was a tape, and had
a pointer to the 'processor' attach routine associated with it..
with the new code I guess I'd need to put
{
T_SEQUENTIAL, T_REMOV, "WangDAT", "Model 1300", "*",
"proc", SC_ONE_LU, 0, mode_wangdat1300
},
as there is no longer a direct pointer to the routine, but just a 'name'
to lookup in the list of installed drivers..
>
> 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.
>
more likely you want to do this for a failing device
in which case you want it to be a 'rogue' type entry.
> > 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:
that's funny.. I thought you wanted to get rid
of NEW_SCSICONF :)
>
> 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".
I agree with this..
each driver needs to be able to add it's own 'rogues as it's configured in..
the init routine can do this.. that's why we put it there..
it becomes a linked list of variable length arrays?
or do we link them all into one big list?
(speed isn't important .. it's run so rarely)
>
> 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?199508211802.LAA24139>