HBAAPI

HBAAPI

[Smart, James]

Folks,

We are reviewing ioctls in our driver and would like some input from the
community :)

We have a fair number of ioctls which provide the functionality of HBAAPI.
HBAAPI is a user-level API for interacting with/configuring FC HBAs. There
are similar efforts occuring for iSCSI, etc.

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. 

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


A couple of additional notes:  

Some of the payload/buffer sizes for the API can exceed 4k in size. Thus,
moving them to sysfs and potentially converting them to multiple operations
is problematic.  Right now, the thought is to leave them as ioctls.  If you
have other ideas, let me know.

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 ?

Thanks

-- James S.

Re: HBAAPI

[James Bottomley]

On Thu, 2004-04-08 at 08:12, Smart, James wrote:
> We have a fair number of ioctls which provide the functionality of HBAAPI.
> HBAAPI is a user-level API for interacting with/configuring FC HBAs. There
> are similar efforts occuring for iSCSI, etc.

Well, as you probably saw from the qla2xxx driver driver submission, the
ioctls got sliced out before final driver acceptance.

> 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. 
> 
> Has there been any thoughts/efforts in doing this in the past ? Any
> recommendations for how this should be implemented ?  Any general thoughts?

Yes, this needs to be done as part of the FC transport class.

> Some of the payload/buffer sizes for the API can exceed 4k in size. Thus,
> moving them to sysfs and potentially converting them to multiple operations
> is problematic.  Right now, the thought is to leave them as ioctls.  If you
> have other ideas, let me know.

There's a binay blob api for sysfs.  If the size is known (or
approximateable) we can probably get the interface fixed to work
correctly.

> 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 ?

Persistent device mapping from the driver is not going in.  Use udev
instead.

James

Re: HBAAPI

[Matthew Wilcox]

On Thu, Apr 08, 2004 at 09:12:13AM -0400, Smart, James wrote:
> We have a fair number of ioctls which provide the functionality of HBAAPI.
> HBAAPI is a user-level API for interacting with/configuring FC HBAs. There
> are similar efforts occuring for iSCSI, etc.
> 
> 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. 
> 
> Has there been any thoughts/efforts in doing this in the past ? Any
> recommendations for how this should be implemented ?  Any general thoughts?

I know this is going to sound a little weird, but take a look at
ethtool_ops (net/core/ethtool.c).  There's a certain amount of cruft
because it was done badly initially and drivers needed to be converted
gradually, but that shouldn't be necessary for a new API.

If all FC/iSCSI drivers have a scsihba_ops API, then at least we
can have typesafe APIs within the kernel for configuring this stuff.
All the parsing gets handled in one place.  It makes the discussion
about how/what/why to expose to userland a different issue ...

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: HBAAPI

[Andreas Herrmann]

"Smart, James" <James.Smart@Emulex.com> wrote:

> Folks,

Hi,

> We are reviewing ioctls in our driver and would like some input from
> the community :)

> We have a fair number of ioctls which provide the functionality of
> HBAAPI.  HBAAPI is a user-level API for interacting with/configuring
> FC HBAs. There are similar efforts occuring for iSCSI, etc.

I've implemented a first stage of the HBA API for the zfcp lldd on
s390 for kernel 2.4. The kernel-user-space communication is also done
via ioctls.

> 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 agree with you.
I think the model described in FC-HBA with a wrapper library and
several vendor libraries maps in Linux to one HBAAPI library, one
"hbaapi"-module (or class) and FC device drivers that register
themselves at the "hbaapi"-module (or class).

I am looking forward to see your proposal. And I offer you to
collaborate in this work.

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

Just some general thoughts about the communication between the kernel
module and the library.

(1) The attributes for adapters, ports etc. could be represented as a
sysfs tree. The library just reads/writes from/to the tree.  Drawbacks
are:

- Performance: too much effort to collect many attributes and convert
the strings into binary data from sysfs if the library handles an HBA
API call

- How to avoid raises if data is (subsequently) collected from
different sysfs attributes for one HBA API call.

- How to implement HBA API calls that send requests into the SAN via
sysfs?

(2) Use binary attributes in sysfs

- up to now not much documented (or lets say: I did not yet feel like
reading the sources;-)

(3) Use ioctl interface

- Seems to me the most obvious way for an implementation

About the kernel module (or device class) and how an lldd has to
register _which_ set of functions ... Hmm, don't know yet.

Of course the kernel module has to care for several things that usually
(up to now) reside in the library. (event handling, tables of available
adapters and ports etc.)

> A couple of additional notes:

> Some of the payload/buffer sizes for the API can exceed 4k in
> size. Thus, moving them to sysfs and potentially converting them to
> multiple operations is problematic.  Right now, the thought is to
> leave them as ioctls.  If you have other ideas, let me know.

I vote for ioctls .

> 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 ?

> Thanks

> -- James S.

BTW, what/where is the sample application at SoureForge you mentioned
above? (Hope it has nothing to do with hbaverify and the
HBA API Common Library at SourceForge.)


Regards,

Andreas

Re: HBAAPI

[Christoph Hellwig]

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?