Re: HBAAPI

[Christoph Hellwig <hch@infradead.org>]

On Thu, Apr 08, 2004 at 09:12:13AM -0400, Smart, James wrote:
> The jist of HBAAPI is that each vendor supplies a "provider" module that
> implements the API for the specific hardware. Ours converts into a lot of
> ioctls. We see this as a great opportunity to remove the need for a
> vendor-specific provider module, and simply have a standard API, supported
> by linux FC drivers. There is already a sample application and template
> provider over on SourceForge that can be leveraged. We are offering to ante
> up a proposal for this API.

I'm not exactly happy with the HBAAPI, like about everything from SNIA
it's a pretty braindead spec.  But if you want a standard implementation
for Linux I'd suggest the different FC HBA Vendors sit together and tell
what additional kernel support they'd need for a _single_ implementation
of that library instead of the loadable module mess.

> Has there been any thoughts/efforts in doing this in the past ? Any
> recommendations for how this should be implemented ?  Any general thoughts?

Most of the HBA ABI functions that are about attribute querying should be
handle through the FC transport attributes.  The entry points ending up
sending down certain scsi commands should invoke SG_IO, for the other
someone has to come up with ideas.

> HBAAPI provides an interface for setting persistent device mappings. What
> are the current thoughts on how driver-level persistent data should be
> maintained/saved/etc ?

Do you mean persistant mappings from WWNNs to scsi target/lun numbers or
mappings of either of those to Linux device names?