| At 10:29 AM 5/15/2002, eeh@netbsd.org 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
| >it?
| >
| >| 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.

O.K.

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.

Eduardo