Re: SNIA iSCSI Management API Public Review

[David Wysochanski <davidw@netapp.com>]

Thanks for taking the time to review and be candid.  More comments
below.

Christoph Hellwig wrote:
> On Tue, Oct 26, 2004 at 03:59:11PM -0400, David Wysochanski wrote:
>  > Christoph Hellwig wrote:
>  > >On Tue, Oct 26, 2004 at 01:29:14PM -0500, Matt Domsch wrote:
>  > > > FYI.
>  > >
>  > >It has the usual SNIA spec quality - aka totally useless.
>  > >
>  >
>  > What specifically is so bad to describe it as totally useless?
> 
> it throws far too much things together, own type and object system,
> functions to deal with firmware.  there's ill suited abstractions like
> the phba, etc..
> 
Sounds like you don't like the modelling.  Keep in mind that a
lot of this came out of the T11 HBA API (for Fibre Channel HBAs
and FC storage management).  Thus, the "phba" idea really fits
the model well.  If you're thinking about it from a software
only perspective, with standard ethernet NICs, it does look
a little strange.

> as I said it's the usual SNIA design by commitee mess.
> 
>  > (Note that this API isn't kernel related.)
> 
> actual it is - as most of the calls end up in an device driver,
> or because the API is totally messed up with networking bits the
> networking layer.
> 
> to take a very concrete example:
> 
> IMA_SetSubnetMask (sets the subnet mask for a specified network port)
> doesn't make any sense at all in Linux with a software iscsi implementation
> as IP addresses and thus netmasks aren't bound to network interfaces at 
> all.
> 

Very good point.
I understand your concern, and I initially had similar ones.

For a software initiator, all of these networking type functions
will not be implemented -- the spec gives you an option to indicate
whether a particular implementation has the networking options.

I and a few others argued a while back these very things -- that
for a software  initiator and typical ethernet NICs, the model didn't
fit as well, and things like the IP stuff should be left to the standard
mechanisms.  As a result, the spec was adjusted a bit to accomodate
the software only case.

A while back I actually came up with a design for an IMA plugin
(the OS dependent part of IMA) to the linux-iscsi software initiator.
As I recall, very little of the plugin, if at all, needed an IOCTL
call to the iscsi driver, but most of it just interfaced with the
userspace stuff.