SNIA iSCSI Management API Public Review
FYI.
----- Forwarded message from Arnold Jones <[email protected]> -----
Date: Tue, 26 Oct 2004 11:27:28 -0400
From: Arnold Jones <[email protected]>
To: [email protected]
SNIA Members,
** PLEASE PASS THIS ON TO YOUR ENGINEERING DEPARTMENT **
The IP Storage Technical Work Group(TWG) has created and reviewed the iSCSI Management API (IMA) Specification and would like review feedback from a wider community. The iSCSI Management API is a C language interface library which allows clients to manage both iSCSI HBAs and iSCSI software initiators in a host system. It provides APIs for the discovery and management of iSCSI initiators. In addition, it provides APIs to discover iSCSI targets and manage the relationships of iSCSI initiators with iSCSI targets.
The DRAFT document is available at:
http://www.snia.org/tech_activities/publicreview/
This public review ends 11/30/2004. Please send comments to the IP Storage TWG [email protected].
NOTE: This review is not limited to SNIA Members and is open to the general public, therefore feel free forward this message to anyone outside of the SNIA.
If you have any questions please contact me at [email protected]
Thanks ...
- Arnold
---
Arnold Jones
Technical Director
Storage Networking Industry Association (SNIA)
[email protected]
407-679-8232
----- End forwarded message -----
Signature · 4 lines
Matt Domsch Sr. Software Engineer, Lead Engineer Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com
Quoted 1 line · Matt Domsch
FYI.
It has the usual SNIA spec quality - aka totally useless.
Quoted 5 lines · Christoph Hellwig
Quoted 1 line · Matt Domsch
FYI.
It has the usual SNIA spec quality - aka totally useless.
What specifically is so bad to describe it as totally useless?
(Note that this API isn't kernel related.)
Quoted 8 lines · David Wysochanski
Quoted 5 lines · Christoph Hellwig
Quoted 1 line · Matt Domsch
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..
as I said it's the usual SNIA design by commitee mess.
Quoted 1 line
(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.
Thanks for taking the time to review and be candid. More comments below.
Quoted 5 lines · Christoph Hellwig
Quoted 4 lines · David Wysochanski
Quoted 3 lines · Christoph Hellwig
Quoted 1 line · Matt Domsch
FYI.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 8 lines
as I said it's the usual SNIA design by commitee mess.
Quoted 1 line
(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.
Quoted 6 lines
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.
Quoted 10 lines
Quoted 4 lines
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.
If you browse the archives you'll find my opinion on the HBA API ;-)