Date: Wed, 07 Oct 1998 01:28:26 -0500 From: Doug Ledford <dledford@dialnet.net> To: Ion Badulescu <ionut@moisil.cs.columbia.edu> Cc: aic7xxx@FreeBSD.ORG Subject: Re: host unique_id for aic7xxx driver Message-ID: <361B0A0A.D9D71EF8@dialnet.net> References: <Pine.LNX.4.02.9810070205360.272-100000@moisil.cs.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Ion Badulescu wrote:
>
> On Tue, 6 Oct 1998, Doug Ledford wrote:
>
> > Elgin Lee wrote:
> > > --- linux/drivers/scsi/aic7xxx.c.pre15 Sat Oct 3 02:03:19 1998
> > > +++ linux/drivers/scsi/aic7xxx.c Sat Oct 3 02:08:04 1998
> > > @@ -7452,6 +7452,7 @@
> > > host->n_io_port = 0xFF;
> > > host->base = (unsigned char *) p->mbase;
> > > host->irq = p->irq;
> > > + host->unique_id = host->host_no;
> > > if (p->features & AHC_WIDE)
> > > {
> > > host->max_id = 16;
> >
> > Something similar, but not identical, has been added for the pre16 code.
>
> Careful though, especially if the final 5.1 driver makes it into 2.0.36,
> as Alan's comments seem to imply. Such a change _will_ break every
> existing installation that's using scsidev (with one controller, so there
> is no problem). Better to keep unique_id = 0 for the first controller and
> give non-zero values to the other controllers.
Which was a problem with the method in the patch above. It uses the host_no
which isn't gauranteed to start at 0. In my version, the unique_id is set
to the same as the aic7xxx instance number. Therefore, the unique_id and
the /proc/scsi/aic7xxx/x number will always be the same. It also means that
if you unload the aic7xxx driver and then reload it, then unlike the host_no
variable, we will go back to 0 and re-use it where as the host_no will get
start at the previous host_no + 1 even if all hosts were removed.
> For the 2.1 kernel it doesn't matter, it breaks scsidev anyway by
> reordering the controllers in proc_fs.h. But for 2.0 it's important to
> follow the principle of the least surprise.
The latest driver doesn't re-order anything in proc_fs.h. It does reorder
the actual order in which it registers the controllers themselves, but
that's because code has been added to properly detect the initial order in
which the BIOS probed the cards and then orders them in the same order. The
older driver didn't used to do that and was very broken in those regards.
This happens with both 2.0 and 2.1 versions of the driver, so that makes the
whole issue a moot point. scsidev will get broken in either kernel version
with the latest patch then (and it overflows the scsidev stuff, and scsidev
isn't a standard item, blah, blah). In short, I'm not too concerned about
scsidev problems. I'm more concerned with people not being able to install
on Ultra2 cards and the like. I'm also more concerned with needing patches
in the driver for scsidev to work. You already need to patch scsidev to
make it work, so I couldn't care less if scsidev is broken, but I want this
driver to work out of the box instead of needing to be patched for scsidev
to work.
--
Doug Ledford <dledford@dialnet.net>
Opinions expressed are my own, but
they should be everybody's.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-aic7xxx" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?361B0A0A.D9D71EF8>