Subject: Re: scsibus capabilities.
To: None <email@example.com, tech-kern@NetBSD.org>
From: None <firstname.lastname@example.org>
Date: 05/15/2002 17:51:26
| At 10:29 AM 5/15/2002, email@example.com wrote:
| >| Analagous to the pcibus_attach_hook in the MI pci code, I'd
| >| to propose that a scsibus_attach_hook be added.
| >What's the scsibus_attach_hook() good for? What goes in?
| >What comes out? What do you expect to be able to do with
| >| This would be a function in the scsipi_channel structure that
| >| if non-null would be called in scsiconf.c:scsibusattach().
| >| The reason for asking for this is that I'm writing a driver
| >| for a new SCSI HBA which is fronted by a embedded processor
| >| (like an I2O IOP but not an I2O IOP) and it presents an
| >| abstracted HBA interface to the host driver. It also tells
| >| things about each SCSI bus (SE, LVD, HVD, FC) that really
| >| should be printed and/or obtained in the scsibusattach.
| >| The alternative would be to add a chan_cap field to the
| >| scsipi_channel and various SCSIBUS_CAP_ bits to describe the
| >| capability of the channels and then let scsibusattach print
| >| those out.
| >So you just want to print out some extra goop? Is there some
| >reason you want this done in the SCSI attach code rather than
| >the HBA driver?
| Because the stuff are attributes of the scsibus, not the HBA.
| Logically in our config system they be printed out as part of
| scsibus attachment. Also, I may have dozens of buses attached
| and as such it'd be real confusing to print this at independently.
| Also, since scsibus attachment is defered it makes it hard to
| match up.
However, you didn't answer the first questions. If you want to
print some message about FC-AL for example I'd think it would
best be done with capabilities. That way other parts of the
code could be made aware of that and use e.g. REPORT_LUNS
rather than scan all possible 4G LUNs.