You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(19) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(2) |
Feb
(6) |
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <ben...@id...> - 2004-05-25 08:08:20
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Yogesh B. <Yogesh.Bansal@Sun.COM> - 2004-04-16 01:31:18
|
Fyi, I'm checking in following changes to ima.h as discussed on this thread. This should have minimal to no impact on source, but a recompile of lib/plugin/tester is advised (esp. for gcc users). Index: ima.h =================================================================== RCS file: /cvsroot/iscsi-mgmt-api/Library/Source/lib/common/ima.h,v retrieving revision 1.2 diff -r1.2 ima.h 194,224c194 < typedef enum { < IMA_STATUS_SUCCESS = 0x00000000, < IMA_STATUS_REBOOT_NECESSARY = 0x00000001, < IMA_STATUS_INCONSISTENT_NODE_PROPERTIES = 0x00000002, < IMA_STATUS_SCSI_STATUS_CONDITION_MET = 0x00000100, < < IMA_STATUS_ERROR = 0x80000000, < IMA_ERROR_NOT_SUPPORTED = 0x80000001, < IMA_ERROR_INSUFFICIENT_MEMORY = 0x80000002, < IMA_ERROR_LAST_PRIMARY_DISCOVERY_METHOD = 0x80000003, < IMA_ERROR_UNEXPECTED_OS_ERROR = 0x80000004, < IMA_ERROR_SYNC_TIMEOUT = 0x80000005, < IMA_ERROR_LU_EXPOSED = 0x80000006, < IMA_ERROR_LU_NOT_EXPOSED = 0x80000007, < IMA_ERROR_LU_IN_USE = 0x80000008, < IMA_ERROR_TARGET_TIMEOUT = 0x80000009, < IMA_ERROR_LOGIN_REJECTED = 0x8000000A, < IMA_ERROR_STATS_COLLECTION_NOT_ENABLED = 0x8000000B, < IMA_ERROR_SCSI_STATUS_CHECK_CONDITION = 0x80000100, < IMA_ERROR_SCSI_STATUS_BUSY = 0x80000101, < IMA_ERROR_SCSI_STATUS_RESERVATION_CONFLICT = 0x80000102, < IMA_ERROR_SCSI_STATUS_TASK_SET_FULL = 0x80000103, < IMA_ERROR_SCSI_STATUS_ACA_ACTIVE = 0x80000104, < IMA_ERROR_SCSI_STATUS_TASK_ABORTED = 0x80000105, < IMA_ERROR_INVALID_PARAMETER = 0xC0000000, < IMA_ERROR_INVALID_OBJECT_TYPE = 0xC0000001, < IMA_ERROR_INCORRECT_OBJECT_TYPE = 0xC0000002, < IMA_ERROR_OBJECT_NOT_FOUND = 0xC0000003, < IMA_ERROR_NAME_TOO_LONG = 0xC0000004, < IMA_ERROR_UNKNOWN_ERROR = 0x8FFFFFFF < } IMA_STATUS; --- > typedef IMA_UINT IMA_STATUS; 226,227c196,200 < #define IMA_SUCCESS(status) ( (IMA_UINT32)(status) & \ < (IMA_UINT32)IMA_STATUS_ERROR == 0 ? \ --- > #define IMA_STATUS_SUCCESS 0x00000000 > #define IMA_STATUS_ERROR 0x80000000 > > #define IMA_SUCCESS(status) ( (IMA_STATUS)(status) & \ > (IMA_STATUS)IMA_STATUS_ERROR == 0 ? \ 229,230c202,203 < #define IMA_ERROR(status) ( (IMA_UINT32)(status) & \ < (IMA_UINT32)IMA_STATUS_ERROR == 0x8000000 ? \ --- > #define IMA_ERROR(status) ( (IMA_STATUS)(status) & \ > (IMA_STATUS)IMA_STATUS_ERROR == 0x8000000 ? \ 231a205,235 > > #define MAKE_IMA_STATUS(x) ((IMA_STATUS)(x)) > #define MAKE_IMA_ERROR(x) ((IMA_STATUS)(IMA_STATUS_ERROR | (x))) > > #define IMA_STATUS_REBOOT_NECESSARY MAKE_IMA_STATUS(1) > #define IMA_STATUS_INCONSISTENT_NODE_PROPERTIES MAKE_IMA_STATUS(2) > #define IMA_STATUS_SCSI_STATUS_CONDITION_MET MAKE_IMA_STATUS(256) > > #define IMA_ERROR_NOT_SUPPORTED MAKE_IMA_ERROR(1) > #define IMA_ERROR_INSUFFICIENT_MEMORY MAKE_IMA_ERROR(2) > #define IMA_ERROR_LAST_PRIMARY_DISCOVERY_METHOD MAKE_IMA_ERROR(3) > #define IMA_ERROR_UNEXPECTED_OS_ERROR MAKE_IMA_ERROR(4) > #define IMA_ERROR_SYNC_TIMEOUT MAKE_IMA_ERROR(5) > #define IMA_ERROR_LU_EXPOSED MAKE_IMA_ERROR(6) > #define IMA_ERROR_LU_NOT_EXPOSED MAKE_IMA_ERROR(7) > #define IMA_ERROR_LU_IN_USE MAKE_IMA_ERROR(8) > #define IMA_ERROR_TARGET_TIMEOUT MAKE_IMA_ERROR(9) > #define IMA_ERROR_LOGIN_REJECTED MAKE_IMA_ERROR(10) > #define IMA_ERROR_STATS_COLLECTION_NOT_ENABLED MAKE_IMA_ERROR(11) > #define IMA_ERROR_SCSI_STATUS_CHECK_CONDITION MAKE_IMA_ERROR(0x100) > #define IMA_ERROR_SCSI_STATUS_BUSY MAKE_IMA_ERROR(0x101) > #define IMA_ERROR_SCSI_STATUS_RESERVATION_CONFLICT MAKE_IMA_ERROR(0x102) > #define IMA_ERROR_SCSI_STATUS_TASK_SET_FULL MAKE_IMA_ERROR(0x103) > #define IMA_ERROR_SCSI_STATUS_ACA_ACTIVE MAKE_IMA_ERROR(0x104) > #define IMA_ERROR_SCSI_STATUS_TASK_ABORTED MAKE_IMA_ERROR(0x105) > #define IMA_ERROR_INVALID_PARAMETER MAKE_IMA_ERROR(0x40000000) > #define IMA_ERROR_INVALID_OBJECT_TYPE MAKE_IMA_ERROR(0x40000001) > #define IMA_ERROR_INCORRECT_OBJECT_TYPE MAKE_IMA_ERROR(0x40000002) > #define IMA_ERROR_OBJECT_NOT_FOUND MAKE_IMA_ERROR(0x40000003) > #define IMA_ERROR_NAME_TOO_LONG MAKE_IMA_ERROR(0x40000004) > #define IMA_ERROR_UNKNOWN_ERROR MAKE_IMA_ERROR(0x0fffffff) Thanks, -Yogesh |
From: David D. <dav...@ve...> - 2004-04-13 01:26:50
|
I have no problem using #defines for IMA statuses. I really don't want to go to a specific size other than unsigned int because it can cause inefficient code to be generated on some platforms. I really don't think any compiler is going to be changing the size of an unsigned int from version to version of the compiler. --- David > -----Original Message----- > From: David Wysochanski [mailto:da...@ne...] > Sent: Thursday, April 08, 2004 6:35 PM > To: Yogesh.Bansal@Sun.COM; David Dillard > Cc: isc...@li...; > ip-...@sn... > Subject: [ip-management] Re: [iscsi-mgmt-api-reflib] > IMA_STATUS should be 4 bytes > > Glad to see someone's looking at the code! > > I agree with you. I think we should clarify the spec as well > in this area, since it often mentions "enumerated types" and > "typedef enum" at various places. We probably should avoid > this altogether. > > David D, do you agree? Can we clarify these types to use a > more explicit sized value? > > > Yogesh Bansal wrote: > > > > > I noticed that in lib/common/ima.h IMA_STATUS type was changed from > > IMA_UINT to enum. > > > > GCC (3.2) makes these IMA_STATUS values as 8 byte constants because > > IMA_ERROR_* value with msb set is larger than max int > (signed 32 bit). > > Sun compiler (5.5) gives a warning but makes the size 4 > byte int, as > > expected. > > > > The ISO C 1999 spec section 6.7.2.2 addresses enum types and allows > > compiler implementation to choose any integer type to fit > enum members. > > Moreover this part of ISO C spec was updated in 1999 release and is > > different from K&R. > > > > This is a potential cause for binary incompatibility based > on the make > > and version of the compiler used. > > > > I propose we revert IMA_STATUS to typedef IMA_UINT, and > have specific > > errors as define's. Casting error status values to int also works. > > > > Thanks, > > -Yogesh > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux > > tutorial presented by Daniel Robbins, President and CEO of GenToo > > technologies. Learn everything from fundamentals to system > > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > > <http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click> > > _______________________________________________ > > iscsi-mgmt-api-reflib mailing list > > isc...@li... > > https://lists.sourceforge.net/lists/listinfo/iscsi-mgmt-api-reflib > > > > > |
From: David W. <da...@ne...> - 2004-04-08 22:35:02
|
Glad to see someone's looking at the code! I agree with you. I think we should clarify the spec as well in this area, since it often mentions "enumerated types" and "typedef enum" at various places. We probably should avoid this altogether. David D, do you agree? Can we clarify these types to use a more explicit sized value? Yogesh Bansal wrote: > > I noticed that in lib/common/ima.h IMA_STATUS type was changed from > IMA_UINT to enum. > > GCC (3.2) makes these IMA_STATUS values as 8 byte constants because > IMA_ERROR_* value with msb set is larger than max int (signed 32 bit). > Sun compiler (5.5) gives a warning but makes the size 4 byte int, as > expected. > > The ISO C 1999 spec section 6.7.2.2 addresses enum types and allows > compiler implementation to choose any integer type to fit enum members. > Moreover this part of ISO C spec was updated in 1999 release and is > different from K&R. > > This is a potential cause for binary incompatibility based on the make > and version of the compiler used. > > I propose we revert IMA_STATUS to typedef IMA_UINT, and have specific > errors as define's. Casting error status values to int also works. > > Thanks, > -Yogesh > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > <http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click> > _______________________________________________ > iscsi-mgmt-api-reflib mailing list > isc...@li... > https://lists.sourceforge.net/lists/listinfo/iscsi-mgmt-api-reflib > |
From: Yogesh B. <Yogesh.Bansal@Sun.COM> - 2004-04-08 22:23:55
|
I noticed that in lib/common/ima.h IMA_STATUS type was changed from IMA_UINT to enum. GCC (3.2) makes these IMA_STATUS values as 8 byte constants because IMA_ERROR_* value with msb set is larger than max int (signed 32 bit). Sun compiler (5.5) gives a warning but makes the size 4 byte int, as expected. The ISO C 1999 spec section 6.7.2.2 addresses enum types and allows compiler implementation to choose any integer type to fit enum members. Moreover this part of ISO C spec was updated in 1999 release and is different from K&R. This is a potential cause for binary incompatibility based on the make and version of the compiler used. I propose we revert IMA_STATUS to typedef IMA_UINT, and have specific errors as define's. Casting error status values to int also works. Thanks, -Yogesh |
From: David W. <da...@ne...> - 2004-02-27 18:03:46
|
A couple questions. 1. Is it really necessary to mention ULP's since iSCSI is only defined for TCP? Perhaps this should be removed entirely from the IMA document, since it seems to be just taking up space and won't be used. If there's a need for it in say, IMA 2.0, we can add it. (I've probably missed something again, so please fill me in.) 2. If we want to leave ULPs in the document, then should the supportedUlps field be a fixed size type (i.e. IMA_UINT32) instead of the potentially variable sized type IMA_UINT? Thanks. |
From: David W. <da...@ne...> - 2004-02-26 23:50:50
|
Ok, here's the code formatting discussion - bear with me, this will be short. I'm not aware of anyone having laid this out, so here goes. In most cases, I don't really care, but we should try to stick to something so things don't look horrible. Here's the issues, I think: 1. length of a line: right now > 80 cols - I'd like to stick to 80 cols if possible, but I'm not going to reformat every line of code 2. indents a) tabs or spaces: looks like mostly tabs, but currenly a mix b) size: indents seem like they're intended at 4 (with a tab=4sp) - I'd prefer all spaces of indent 4, but could live with tabs 3. Brackets: right now non-k/r - fine with me 4. Encouraging formatting - some editors recognize certain comments as formatting schemes; we could use this to help encourage consistent formatting 5. filenames/directories: - suggest all lower case, and use of dashes if need be - I'm not going to go through and change existing dir's, but I have changed a few filenames to lowercase |
From: David D. <dav...@ve...> - 2004-02-26 22:37:39
|
I agree, there's no point in branching... > -----Original Message----- > From: David Wysochanski [mailto:da...@ne...] > Sent: Thursday, February 26, 2004 5:17 PM > To: isc...@li...; > ip-...@sn... > Subject: [ip-management] I'm updating the common library code > to be 1.0.1 compliant > > Since nobody has picked this up, I'm going to get in there and do it. > Holler if for some reason you object or would like to help. > > I'd like to get it up to 1.0.1 and then tag the version. > Since we're going to be getting a 1.1 fairly soon, I'm > thinking it's not worth branching at this point. (I think > 1.0.1 code will just be a stepping stone to what people will > really start using.) > |
From: David W. <da...@ne...> - 2004-02-26 22:18:57
|
Since nobody has picked this up, I'm going to get in there and do it. Holler if for some reason you object or would like to help. I'd like to get it up to 1.0.1 and then tag the version. Since we're going to be getting a 1.1 fairly soon, I'm thinking it's not worth branching at this point. (I think 1.0.1 code will just be a stepping stone to what people will really start using.) |
From: David W. <da...@ne...> - 2004-02-23 20:02:14
|
I'd like to make a proposal for naming conventions for the IMA common library and plugins, as well as their locations. I'm mainly dealing with Linux for my implementation, so I'm soliciting feedback for my proposal (I already have one person's feedback.) Once I have the naming conventions and locations solidified, I intend to create RPMs containing the common library and header files for plugin development. In addition, I'm hoping those dealing with other operating systems will start thinking about what they should do on their OS of interest. In the end, all these conventions can be added as documentation in the sourceforge project (under the newly created "Docs" directory, and can be used as a guide for plugin developers. For Linux, I propose the following general naming conventions: 1) Use "libima-common" to denote things related to the IMA common library. This naming is consistent with standard Unix conventions. A smaller name could be used (libima), but the longer name hopefully avoids confusion with already existing libraries such as IMAP (libimap). 2) Use "libima-plugin-<vendorSpecificName>" to denote things related to a vendors' plugin 3) Versioning will be handled by adding the numbers at the end of library names and directories. Specific version numbers should reflect the version of the IMA document that is supported, and any patch number can be used for vendor-specific bugfixes. Symlinks will used to denote the current version. Specifically, these general conventions will lead to a number of specific naming conventions for both the IMA common library and any IMA plugins. The specific conventions for the common library will be: 4) The common library will be located in the following location: /usr/lib/ 5) IMA common library should be named as follows: libima-common-X-Y-Z-patch#.so 6) Header files for the common library and to be used for plugin development will be located at the following location: /usr/include/libima-common-X-Y-Z-patch#/ 7) Documentation for the common library will go in the following directory: /usr/share/doc/packages/libima-common-X-Y-Z-patch# The specific conventions for the IMA plugins will be: 8) Plugin libraries will be located in the following directory: /usr/lib/ 9) IMA plugins should be named as follows: libima-plugin-<vendorSpecificName>-X-Y-Z-patch#.so 10) Documentation for a vendor's plugin will be located in the following directory: /usr/share/doc/packages/libima-plugin-<vendorSpecificName>-X-Y-Z-patch# |
From: David W. <da...@ne...> - 2004-02-20 19:41:29
|
I've been working with the common library as well as a plugin for the linux software initiator. I'd like to package the common library as RPMs (one will contain the ima.h and ima-plugin.h header files) that can be used by plugin developers and included in Linux distributions. To this end, I'd like to make the following changes to the common library: 1) Make all header files lower case. In particular, Ima.h and ImaPlugin.h will become ima.h and ima-plugin.h, respectively. 2) Create a "Build/Linux" directory at the top level of the directory structure (the "Build" subdirectory) that will include the ".spec" file(s) appropriate for building common library RPMs 3) Use a well-defined location for plugins, rather than an entry in the configuration file. For linux, this is likely to be /usr/share/something. I'm not sure whether we even need a configuration file. Right now it seems we do not if we make this change. 4) Create a "Docs" subdirectory at the top level. This would contain the source license, README file, etc 5) Turn the html version of the SNIA license into a text version (simpler to read) Please reply if you have objections to the proposed changes. I will likely check in the changes if I don't hear from anyone in a day or so. Thanks. |
From: David D. <dav...@ve...> - 2004-01-23 02:52:37
|
> The current common library code doesn't tell a plugin about > the common node name. You're right, there's a bug in the current code in the library. As I look at the code, there's some other things that are questionable in there too. --- David |
From: David W. <da...@ne...> - 2004-01-23 02:07:55
|
The current common library code doesn't tell a plugin about the common node name. Thus, any plugin currently is forced into non-shared nodes, which is bad. I've filed a bug on sourceforge for the common library, bug ID 882640. I'd guess we'd fix this by adding the shared node name as another parameter to the "Initialize" function that a plugin must provide. http://sourceforge.net/tracker/index.php?func=detail&aid=882640&group_id=58072&atid=486421 David Dillard wrote: > > To handle (a), the IMA common library could generate a > > default name upon initialization, and then pass this to each > > plugin upon registration. > > Then if > > IMA_SetNodeName is called, each plugin would be called as well. > > > > Such an implementation would add even more importance to > > defining the plugin<-->common library interface in a clear way. > > A plugin/driver is supposed to persist the node name whenever it is > set. An > IMA client should not be required to run for iSCSI I/O to take place. > |
From: David W. <da...@ne...> - 2003-12-17 18:11:39
|
On your first question, I am planning to implement 1-2, but not 3-4. The reason is the same that Paul stated (there's currently no need to do LUN masking on the host side). As far as "anything else", I'm hoping to implement everything needed for compliance, but not much else. One other thing I'd like to see is an API call to return the list of final negotiated values for a given target. Since we already have the IMA_Get* and IMA_Set* APIs, this seems like a logical extension, and one that I'm sure a number of management app's will use. Some proprietary ones I've seen currently provide this information, so the lack of it in IMA is something that should be remedied. The time to address this might be later when more extensive session/connection management is addressed. I know we talked about this before offline, but I wanted to state it for others to see. Apologies if this feedback is coming too late. As others, my priorities are set by those above me, and it is not until recently that IMA has become on my radar screen. The intent is not to in any way derail the current spec, but to point out areas of possible improvement so we can make it better in the future (whenever that is). David Dillard wrote: > On the particular case of a not being able to show link aggregation > I'd say > fine, just have a 1 to 1 mapping from LNP to PNP. > > More generally, I have a question: what functionality ARE you planning on > providing in the plugin? > > It seems like it'd be: > > 1. List of targets > 2. SCSI commands to targets > 3. Expose LU > 4. Unexpose LU > > Anything else? > > > > PS: Why oh why didn't you guys start shooting arrows at IMA earlier??? > > > > > -----Original Message----- > > From: Paul von Behren [mailto:Paul.Vonbehren@Sun.COM] > > Sent: Tuesday, December 16, 2003 3:52 PM > > To: David Dillard > > Cc: 'David W.'; ip-...@sn...; > > isc...@li... > > Subject: Re: feedback requested regarding IMA plugins for > > software iSCSI i nitiators > > > > > > > > David Dillard wrote: > > > > > Reply inline below... > > > > > > > > >>Representation of IMA 1.0 Constructs in a Software Initiator Plugin > > >> > > >>The IMA 1.0 specification outlines a model for management of iSCSI > > >>initiators that is based on underlying constructs involving > > physical > > >>HBAs (PHBA), physical network ports (PNP), logical HBAs (LHBA), > > >>logical network ports (LNP), and network portals (NP) Of these > > >>constructs, only the LHBA seems to fit well in a software initiator > > >>plugin environment. > > > > > > > > > Surprise! I disagree with this. :-) > > > > > > - A NIC qualifies as a PHBA. > > > - The ports on a NIC are certainly PNPs. > > > - A link aggregate of ports (originally defined for TCP/IP) > > is an LNP. > > > - A network portal is an iSCSI construct, not an IMA > > construct, so it > > > applies to any iSCSI implementation ;-) > > > > > > > The problem is that IMA (and iSCSI in general) require APIs > > that may not exist in a legacy TCP/IP stack and reproduces > > capabilities that may may exist in the stack. So those of us > > trying to leverage existing software need a way to get > > reasonably close to IMA without rewriting the TCP/IP stack. > > There is a certain amount of detail (such as link > > aggregation) that is not exposed today in TCP/IP and we will > > not expose in our iSCSI implmentation. > > > > So I'm with David W here; I'd like to see a recommended > > approach for plugin authors to say - this plugin does not > > offer fine-grained control over the HBAs, but does comply to > > rest of IMA. I think also need a property to let a client > > know they are dealing with this type of plugin. > > > > Paul > > > > > > > > > > > > > >>Existence and management of the other entities make sense when an > > >>iSCSI HBA is present. > > >>However, when a software initiator is present, the > > initiator functions > > >>as just another TCP/IP network protocol, unaware and > > unconcerned about > > >>the underlying physical HBAs, physical ports, etc. > > > > > > > > > The initiator may not need to know about these things to > > function, but > > > management software very much wants to know about such things. > > > > > > > > > > > > > > >>A software initiator is subject to all the > > >>underlying networking configuration just as any other > > >>protocol in the machine. > > >>In fact, in a software initiator situation, management of > > >>things like IP addresses, gateways, etc, from an IMA context > > >>is probably undesirable since the changing of these values > > >>might affect other protocols. > > > > > > > > > True. That's why the IMA provides a way for the plugin to > > communicate to a > > > client what's settable and what isn't settable. NONE of > > the things you > > > mentioned is REQUIRED to be settable. Next to nothing in the IMA is > > > REQUIRED to be settable. > > > > > > > > > > > > > > >>This is also not the norm for > > >>other storage networking protocols such as NFS. Furthermore, > > >>even accurate enumeration of the actual physical HBAs, > > >>physical ports, etc, from a software initiator plugin > > >>perspective may be very difficult when one considers the > > >>complex networking configurations that may arise, and the > > >>fact that some information (i.e. what actual hardware exists, > > >>link speeds, etc.) is only available to the device driver itself. > > > > > > > > > Sure. So, the device driver should be enhanced to expose > > the necessary > > > information to the plugin via ioctls or other means. > > > > > > > > > > > > > > >>Unfortunately, because of the way the IMA was designed, a > > >>useful plugin cannot ignore the construct of the PHBA and > > >>simply return a NULL list in response to the > > >>IMA_GetPhbaOidList() call, since the iSCSI target discovery > > >>mechanisms are based on a PHBA. > > > > > > > > > This is true. Nor should it. The PHBA is the physical > > medium upon which > > > physical network ports are mounted. For a software > > initiator these are > > > NICS. > > > > > > > > > > > > > > >>The other constructs such as > > >>the NP, LNP, and PNP might be ignored, in which case the > > >>corresponding IMA_Get*OidList() calls would return NULL lists > > >>for the plugin. > > > > > > > > > That would be very bad karma :-) And probably something > > that I should > > > revise the spec to prohibit. > > > > > > > > > > > >>However, this was clearly not the intent of > > >>the IMA, as detailed in the UML Class Relationship Diagram on > > >>p. 12 of the IMA specification, and the definition of these > > >>constructs. As a result it's not clear what implications > > >>such an approach (i.e. having a PHBA present and other > > >>constructs absent) would have to applications who use an IMA > > >>containing this type of plugin. > > >> > > >>For these reasons, one possible approach for a software > > >>initiator is to virtualize the needed constructs as follows: > > >> > > >> 1. A single virtualized PHBA that represents the > > software initiator > > >> 2. A single virtualized PNP that hangs off the virtualized PHBA. > > >> 3. A single LHBA. Software initiators typically must present > > >> themselves to the operating system just as another SCSI host > > >> adapter, and in this way, fit the definition of > > >>"Logical HBA", as > > >> outlined on p. 10 of the IMA specification, that states, "A > > >> logical HBA (LHBA) is a representation of a parallel > > SCSI HBA to > > >> the operating system". > > >> 4. A single LNP that hangs off the Logical HBA, and maps to the > > >> single virtualized PNP. > > >> 5. A single virtualized NP, that represents any real > > network portal > > >> that may be used by the software initiator. > > >> > > >>Taking this approach will have the drawback that any > > >>management application that wishes to show targets or LUNs > > >>mapped to a particular PHBA, PNP, network portal, etc, or > > >>otherwise manage the underlying IP network will not be able > > >>to do so. In addition, the IP addresses, MAC addresses, > > >>physical link information, etc. will not be real values, but > > >>will contain zeros or invalid data that is easy to recognize. > > >>However, as was stated earlier, in the software initiator > > >>case, well-known utilities already exist (i.e. ifconfig, > > >>netstat, etc) to examine and manage the underlying network > > >>infrastructure, so these drawbacks seem to be mitigated. > > > > > > > > > Virtualizing physical objects is something to be avoided. > > The FC HBA API > > > suffered from this which is why both physical and logical > > objects are in the > > > IMA. > > > > > > There are ways for a software initiator to satisfy the > > requirements of the > > > IMA, as I've outlined above. I STRONGLY urge you to not subvert the > > > intented functionality in your plugin. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > <http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click> > _______________________________________________ > iscsi-mgmt-api-reflib mailing list > isc...@li... > https://lists.sourceforge.net/lists/listinfo/iscsi-mgmt-api-reflib > |
From: Paul v. B. <Paul.Vonbehren@Sun.COM> - 2003-12-17 00:17:36
|
David Dillard wrote: >>> 3. Expose LU >>> 4. Unexpose LU >> >>No, we are assuming this is managed from targets (LUN Masking). > > > Huh? IMA_ExposeLu exposes the LU to the OS, not to the initiator. Understood. Our plan is to have the initiator code expose all LUNs per information reported in SCSI Report LUNs and Inquiry (as is done with other transports) rather than changing the user experience for iSCSI. Note that we don't provide any per-LU management in FC Persistent Binding either - we allow you to specify which I_T pairs will be enumerated by the drivers, but all usable LUNs within the I_T pair are enumerated. It seems like all arrays provide this capability (LUN Masking) now, so the customer will have already had to use the array management interface to decide which initiators will be granted access to LUNs. Assuming the customer has already done this once, we didn't see a good reason why the customer would need to override this decision on the initiator side. Paul |
From: David W. <da...@ne...> - 2003-12-16 23:04:54
|
Thanks for the feedback. My responses below. In general the difficulty lies in an accurate representation of the PHBA, PNP, NP, etc constructs in a software initiator environment. This is because the writer of a software initiator plugin does not have access to all the information that the writer of a hardware initiator plugin would. David Dillard wrote: > Reply inline below... > > > Representation of IMA 1.0 Constructs in a Software Initiator Plugin > > > > The IMA 1.0 specification outlines a model for management of > > iSCSI initiators that is based on underlying constructs > > involving physical HBAs (PHBA), physical network ports > > (PNP), logical HBAs (LHBA), logical network ports (LNP), and > > network portals (NP) Of these constructs, only the LHBA seems > > to fit well in a software initiator plugin environment. > > Surprise! I disagree with this. :-) > > - A NIC qualifies as a PHBA. > - The ports on a NIC are certainly PNPs. > - A link aggregate of ports (originally defined for TCP/IP) is an LNP. > - A network portal is an iSCSI construct, not an IMA construct, so it > applies to any iSCSI implementation ;-) > Right. I know they are in essence most likely all present. I did say "fit well". Maybe that's not the right term. Maybe "really necessary for iSCSI management" is a better term? Perhaps this is an area for debate, but my whole premise is that in a software initiator environment there won't be a need to manage the underlying TCP/IP infrastructure since there's already a means to do that. In an HBA environment, you absolutely need it. But I think with software only, it's really up for debate and IMO just gets in the way. > > > > Existence and management of the other entities make sense > > when an iSCSI HBA is present. > > However, when a software initiator is present, the initiator > > functions as just another TCP/IP network protocol, unaware > > and unconcerned about the underlying physical HBAs, physical > > ports, etc. > > The initiator may not need to know about these things to function, but > management software very much wants to know about such things. > But management software on top of IMA is not going to manage the general TCP/IP infrastructure on a host. That's my whole point about the constructs not "fitting well". > > > > A software initiator is subject to all the > > underlying networking configuration just as any other > > protocol in the machine. > > In fact, in a software initiator situation, management of > > things like IP addresses, gateways, etc, from an IMA context > > is probably undesirable since the changing of these values > > might affect other protocols. > > True. That's why the IMA provides a way for the plugin to communicate > to a > client what's settable and what isn't settable. NONE of the things you > mentioned is REQUIRED to be settable. Next to nothing in the IMA is > REQUIRED to be settable. > Point taken. So if all these things could be reliably enumerated with a reasonable amount of work, I would do it that way. But I don't think this is possible at this point. > > > > This is also not the norm for > > other storage networking protocols such as NFS. Furthermore, > > even accurate enumeration of the actual physical HBAs, > > physical ports, etc, from a software initiator plugin > > perspective may be very difficult when one considers the > > complex networking configurations that may arise, and the > > fact that some information (i.e. what actual hardware exists, > > link speeds, etc.) is only available to the device driver itself. > > Sure. So, the device driver should be enhanced to expose the necessary > information to the plugin via ioctls or other means. > This is really an unrealistic expectation to place on any software initiator plugin, since what you're really talking about is all networking drivers in the operating system. > > > > Unfortunately, because of the way the IMA was designed, a > > useful plugin cannot ignore the construct of the PHBA and > > simply return a NULL list in response to the > > IMA_GetPhbaOidList() call, since the iSCSI target discovery > > mechanisms are based on a PHBA. > > This is true. Nor should it. The PHBA is the physical medium upon which > physical network ports are mounted. For a software initiator these are > NICS. > Honestly, I'd like to see discovery _not_ be tied to a Phba. It's not clear how calls like IMA_AddPhbaStaticDiscoveryTarget() work in certain environments. What if the underlying route to a target changes, and thus the Phba it goes over changes? What about interfaces that span multiple Phbas (i.e. bonded drivers), or aren't really Phbas at all (i.e. IP tunnel, SLIP, PPP)? > > > > The other constructs such as > > the NP, LNP, and PNP might be ignored, in which case the > > corresponding IMA_Get*OidList() calls would return NULL lists > > for the plugin. > > That would be very bad karma :-) And probably something that I should > revise the spec to prohibit. > > > > However, this was clearly not the intent of > > the IMA, as detailed in the UML Class Relationship Diagram on > > p. 12 of the IMA specification, and the definition of these > > constructs. As a result it's not clear what implications > > such an approach (i.e. having a PHBA present and other > > constructs absent) would have to applications who use an IMA > > containing this type of plugin. > > > > For these reasons, one possible approach for a software > > initiator is to virtualize the needed constructs as follows: > > > > 1. A single virtualized PHBA that represents the software initiator > > 2. A single virtualized PNP that hangs off the virtualized PHBA. > > 3. A single LHBA. Software initiators typically must present > > themselves to the operating system just as another SCSI host > > adapter, and in this way, fit the definition of > > "Logical HBA", as > > outlined on p. 10 of the IMA specification, that states, "A > > logical HBA (LHBA) is a representation of a parallel SCSI HBA to > > the operating system". > > 4. A single LNP that hangs off the Logical HBA, and maps to the > > single virtualized PNP. > > 5. A single virtualized NP, that represents any real network portal > > that may be used by the software initiator. > > > > Taking this approach will have the drawback that any > > management application that wishes to show targets or LUNs > > mapped to a particular PHBA, PNP, network portal, etc, or > > otherwise manage the underlying IP network will not be able > > to do so. In addition, the IP addresses, MAC addresses, > > physical link information, etc. will not be real values, but > > will contain zeros or invalid data that is easy to recognize. > > However, as was stated earlier, in the software initiator > > case, well-known utilities already exist (i.e. ifconfig, > > netstat, etc) to examine and manage the underlying network > > infrastructure, so these drawbacks seem to be mitigated. > > Virtualizing physical objects is something to be avoided. The FC HBA API > suffered from this which is why both physical and logical objects are > in the > IMA. > > There are ways for a software initiator to satisfy the requirements of > the > IMA, as I've outlined above. I STRONGLY urge you to not subvert the > intented functionality in your plugin. > I really don't want to subvert the intent of the spec, I really don't. However, as I've outlined above, it seems I have only 2 choices, with the following pluses and minuses: 1. Attempt to enumerate the underlying TCP/IP infrastructure + would be true to the intent of IMA - would be a lot of work to attempt accurate enumeration of the underlying TCP/IP infrastructure - only a couple values like "link speed" would be faked, or I'd need to enhance every networking driver to export this information - there already exists management applications to enumerate and manage all these values, so it's likely this functionality will not be used much, if at all - it's likely I'll get the enumeration wrong for some cases (i.e. bonding drivers, IP tunnels, PPP, etc) 2. Don't attempt to enumerate underlying TCP/IP infrastructure - would not be true to the intent of IMA + would be much easier than attempting to accurately enumerate the underlying architecture +/- all IP address and MAC values would not be reliable, but there would be no mix of good information with bad information |
From: David D. <dav...@ve...> - 2003-12-16 22:25:47
|
> > 3. Expose LU > > 4. Unexpose LU > > No, we are assuming this is managed from targets (LUN Masking). Huh? IMA_ExposeLu exposes the LU to the OS, not to the initiator. |
From: Paul v. B. <Paul.Vonbehren@Sun.COM> - 2003-12-16 22:07:39
|
David Dillard wrote: > On the particular case of a not being able to show link aggregation I'd say > fine, just have a 1 to 1 mapping from LNP to PNP. That seemed like the most appropriate approach. > > More generally, I have a question: what functionality ARE you planning on > providing in the plugin? > > It seems like it'd be: > > 1. List of targets > 2. SCSI commands to targets Yes > 3. Expose LU > 4. Unexpose LU No, we are assuming this is managed from targets (LUN Masking). > > Anything else? Looks like we can provide all the other mandatory interfaces. > > > PS: Why oh why didn't you guys start shooting arrows at IMA earlier??? Funding :-! Paul > > > > >>-----Original Message----- >>From: Paul von Behren [mailto:Paul.Vonbehren@Sun.COM] >>Sent: Tuesday, December 16, 2003 3:52 PM >>To: David Dillard >>Cc: 'David W.'; ip-...@sn...; >>isc...@li... >>Subject: Re: feedback requested regarding IMA plugins for >>software iSCSI i nitiators >> >> >> >>David Dillard wrote: >> >> >>>Reply inline below... >>> >>> >>> >>>>Representation of IMA 1.0 Constructs in a Software Initiator Plugin >>>> >>>>The IMA 1.0 specification outlines a model for management of iSCSI >>>>initiators that is based on underlying constructs involving >> >>physical >> >>>>HBAs (PHBA), physical network ports (PNP), logical HBAs (LHBA), >>>>logical network ports (LNP), and network portals (NP) Of these >>>>constructs, only the LHBA seems to fit well in a software initiator >>>>plugin environment. >>> >>> >>>Surprise! I disagree with this. :-) >>> >>>- A NIC qualifies as a PHBA. >>>- The ports on a NIC are certainly PNPs. >>>- A link aggregate of ports (originally defined for TCP/IP) >> >>is an LNP. >> >>>- A network portal is an iSCSI construct, not an IMA >> >>construct, so it >> >>>applies to any iSCSI implementation ;-) >>> >> >>The problem is that IMA (and iSCSI in general) require APIs >>that may not exist in a legacy TCP/IP stack and reproduces >>capabilities that may may exist in the stack. So those of us >>trying to leverage existing software need a way to get >>reasonably close to IMA without rewriting the TCP/IP stack. >>There is a certain amount of detail (such as link >>aggregation) that is not exposed today in TCP/IP and we will >>not expose in our iSCSI implmentation. >> >>So I'm with David W here; I'd like to see a recommended >>approach for plugin authors to say - this plugin does not >>offer fine-grained control over the HBAs, but does comply to >>rest of IMA. I think also need a property to let a client >>know they are dealing with this type of plugin. >> >>Paul >> >> >>> >>> >>> >>>>Existence and management of the other entities make sense when an >>>>iSCSI HBA is present. >>>>However, when a software initiator is present, the >> >>initiator functions >> >>>>as just another TCP/IP network protocol, unaware and >> >>unconcerned about >> >>>>the underlying physical HBAs, physical ports, etc. >>> >>> >>>The initiator may not need to know about these things to >> >>function, but >> >>>management software very much wants to know about such things. >>> >>> >>> >>> >>> >>>>A software initiator is subject to all the >>>>underlying networking configuration just as any other >>>>protocol in the machine. >>>>In fact, in a software initiator situation, management of >>>>things like IP addresses, gateways, etc, from an IMA context >>>>is probably undesirable since the changing of these values >>>>might affect other protocols. >>> >>> >>>True. That's why the IMA provides a way for the plugin to >> >>communicate to a >> >>>client what's settable and what isn't settable. NONE of >> >>the things you >> >>>mentioned is REQUIRED to be settable. Next to nothing in the IMA is >>>REQUIRED to be settable. >>> >>> >>> >>> >>> >>>>This is also not the norm for >>>>other storage networking protocols such as NFS. Furthermore, >>>>even accurate enumeration of the actual physical HBAs, >>>>physical ports, etc, from a software initiator plugin >>>>perspective may be very difficult when one considers the >>>>complex networking configurations that may arise, and the >>>>fact that some information (i.e. what actual hardware exists, >>>>link speeds, etc.) is only available to the device driver itself. >>> >>> >>>Sure. So, the device driver should be enhanced to expose >> >>the necessary >> >>>information to the plugin via ioctls or other means. >>> >>> >>> >>> >>> >>>>Unfortunately, because of the way the IMA was designed, a >>>>useful plugin cannot ignore the construct of the PHBA and >>>>simply return a NULL list in response to the >>>>IMA_GetPhbaOidList() call, since the iSCSI target discovery >>>>mechanisms are based on a PHBA. >>> >>> >>>This is true. Nor should it. The PHBA is the physical >> >>medium upon which >> >>>physical network ports are mounted. For a software >> >>initiator these are >> >>>NICS. >>> >>> >>> >>> >>> >>>>The other constructs such as >>>>the NP, LNP, and PNP might be ignored, in which case the >>>>corresponding IMA_Get*OidList() calls would return NULL lists >>>>for the plugin. >>> >>> >>>That would be very bad karma :-) And probably something >> >>that I should >> >>>revise the spec to prohibit. >>> >>> >>> >>> >>>>However, this was clearly not the intent of >>>>the IMA, as detailed in the UML Class Relationship Diagram on >>>>p. 12 of the IMA specification, and the definition of these >>>>constructs. As a result it's not clear what implications >>>>such an approach (i.e. having a PHBA present and other >>>>constructs absent) would have to applications who use an IMA >>>>containing this type of plugin. >>>> >>>>For these reasons, one possible approach for a software >>>>initiator is to virtualize the needed constructs as follows: >>>> >>>> 1. A single virtualized PHBA that represents the >> >>software initiator >> >>>> 2. A single virtualized PNP that hangs off the virtualized PHBA. >>>> 3. A single LHBA. Software initiators typically must present >>>> themselves to the operating system just as another SCSI host >>>> adapter, and in this way, fit the definition of >>>>"Logical HBA", as >>>> outlined on p. 10 of the IMA specification, that states, "A >>>> logical HBA (LHBA) is a representation of a parallel >> >>SCSI HBA to >> >>>> the operating system". >>>> 4. A single LNP that hangs off the Logical HBA, and maps to the >>>> single virtualized PNP. >>>> 5. A single virtualized NP, that represents any real >> >>network portal >> >>>> that may be used by the software initiator. >>>> >>>>Taking this approach will have the drawback that any >>>>management application that wishes to show targets or LUNs >>>>mapped to a particular PHBA, PNP, network portal, etc, or >>>>otherwise manage the underlying IP network will not be able >>>>to do so. In addition, the IP addresses, MAC addresses, >>>>physical link information, etc. will not be real values, but >>>>will contain zeros or invalid data that is easy to recognize. >>>>However, as was stated earlier, in the software initiator >>>>case, well-known utilities already exist (i.e. ifconfig, >>>>netstat, etc) to examine and manage the underlying network >>>>infrastructure, so these drawbacks seem to be mitigated. >>> >>> >>>Virtualizing physical objects is something to be avoided. >> >>The FC HBA API >> >>>suffered from this which is why both physical and logical >> >>objects are in the >> >>>IMA. >>> >>>There are ways for a software initiator to satisfy the >> >>requirements of the >> >>>IMA, as I've outlined above. I STRONGLY urge you to not subvert the >>>intented functionality in your plugin. >> |
From: David D. <dav...@ve...> - 2003-12-16 20:58:38
|
On the particular case of a not being able to show link aggregation I'd say fine, just have a 1 to 1 mapping from LNP to PNP. More generally, I have a question: what functionality ARE you planning on providing in the plugin? It seems like it'd be: 1. List of targets 2. SCSI commands to targets 3. Expose LU 4. Unexpose LU Anything else? PS: Why oh why didn't you guys start shooting arrows at IMA earlier??? > -----Original Message----- > From: Paul von Behren [mailto:Paul.Vonbehren@Sun.COM] > Sent: Tuesday, December 16, 2003 3:52 PM > To: David Dillard > Cc: 'David W.'; ip-...@sn...; > isc...@li... > Subject: Re: feedback requested regarding IMA plugins for > software iSCSI i nitiators > > > > David Dillard wrote: > > > Reply inline below... > > > > > >>Representation of IMA 1.0 Constructs in a Software Initiator Plugin > >> > >>The IMA 1.0 specification outlines a model for management of iSCSI > >>initiators that is based on underlying constructs involving > physical > >>HBAs (PHBA), physical network ports (PNP), logical HBAs (LHBA), > >>logical network ports (LNP), and network portals (NP) Of these > >>constructs, only the LHBA seems to fit well in a software initiator > >>plugin environment. > > > > > > Surprise! I disagree with this. :-) > > > > - A NIC qualifies as a PHBA. > > - The ports on a NIC are certainly PNPs. > > - A link aggregate of ports (originally defined for TCP/IP) > is an LNP. > > - A network portal is an iSCSI construct, not an IMA > construct, so it > > applies to any iSCSI implementation ;-) > > > > The problem is that IMA (and iSCSI in general) require APIs > that may not exist in a legacy TCP/IP stack and reproduces > capabilities that may may exist in the stack. So those of us > trying to leverage existing software need a way to get > reasonably close to IMA without rewriting the TCP/IP stack. > There is a certain amount of detail (such as link > aggregation) that is not exposed today in TCP/IP and we will > not expose in our iSCSI implmentation. > > So I'm with David W here; I'd like to see a recommended > approach for plugin authors to say - this plugin does not > offer fine-grained control over the HBAs, but does comply to > rest of IMA. I think also need a property to let a client > know they are dealing with this type of plugin. > > Paul > > > > > > > > >>Existence and management of the other entities make sense when an > >>iSCSI HBA is present. > >>However, when a software initiator is present, the > initiator functions > >>as just another TCP/IP network protocol, unaware and > unconcerned about > >>the underlying physical HBAs, physical ports, etc. > > > > > > The initiator may not need to know about these things to > function, but > > management software very much wants to know about such things. > > > > > > > > > >>A software initiator is subject to all the > >>underlying networking configuration just as any other > >>protocol in the machine. > >>In fact, in a software initiator situation, management of > >>things like IP addresses, gateways, etc, from an IMA context > >>is probably undesirable since the changing of these values > >>might affect other protocols. > > > > > > True. That's why the IMA provides a way for the plugin to > communicate to a > > client what's settable and what isn't settable. NONE of > the things you > > mentioned is REQUIRED to be settable. Next to nothing in the IMA is > > REQUIRED to be settable. > > > > > > > > > >>This is also not the norm for > >>other storage networking protocols such as NFS. Furthermore, > >>even accurate enumeration of the actual physical HBAs, > >>physical ports, etc, from a software initiator plugin > >>perspective may be very difficult when one considers the > >>complex networking configurations that may arise, and the > >>fact that some information (i.e. what actual hardware exists, > >>link speeds, etc.) is only available to the device driver itself. > > > > > > Sure. So, the device driver should be enhanced to expose > the necessary > > information to the plugin via ioctls or other means. > > > > > > > > > >>Unfortunately, because of the way the IMA was designed, a > >>useful plugin cannot ignore the construct of the PHBA and > >>simply return a NULL list in response to the > >>IMA_GetPhbaOidList() call, since the iSCSI target discovery > >>mechanisms are based on a PHBA. > > > > > > This is true. Nor should it. The PHBA is the physical > medium upon which > > physical network ports are mounted. For a software > initiator these are > > NICS. > > > > > > > > > >>The other constructs such as > >>the NP, LNP, and PNP might be ignored, in which case the > >>corresponding IMA_Get*OidList() calls would return NULL lists > >>for the plugin. > > > > > > That would be very bad karma :-) And probably something > that I should > > revise the spec to prohibit. > > > > > > > >>However, this was clearly not the intent of > >>the IMA, as detailed in the UML Class Relationship Diagram on > >>p. 12 of the IMA specification, and the definition of these > >>constructs. As a result it's not clear what implications > >>such an approach (i.e. having a PHBA present and other > >>constructs absent) would have to applications who use an IMA > >>containing this type of plugin. > >> > >>For these reasons, one possible approach for a software > >>initiator is to virtualize the needed constructs as follows: > >> > >> 1. A single virtualized PHBA that represents the > software initiator > >> 2. A single virtualized PNP that hangs off the virtualized PHBA. > >> 3. A single LHBA. Software initiators typically must present > >> themselves to the operating system just as another SCSI host > >> adapter, and in this way, fit the definition of > >>"Logical HBA", as > >> outlined on p. 10 of the IMA specification, that states, "A > >> logical HBA (LHBA) is a representation of a parallel > SCSI HBA to > >> the operating system". > >> 4. A single LNP that hangs off the Logical HBA, and maps to the > >> single virtualized PNP. > >> 5. A single virtualized NP, that represents any real > network portal > >> that may be used by the software initiator. > >> > >>Taking this approach will have the drawback that any > >>management application that wishes to show targets or LUNs > >>mapped to a particular PHBA, PNP, network portal, etc, or > >>otherwise manage the underlying IP network will not be able > >>to do so. In addition, the IP addresses, MAC addresses, > >>physical link information, etc. will not be real values, but > >>will contain zeros or invalid data that is easy to recognize. > >>However, as was stated earlier, in the software initiator > >>case, well-known utilities already exist (i.e. ifconfig, > >>netstat, etc) to examine and manage the underlying network > >>infrastructure, so these drawbacks seem to be mitigated. > > > > > > Virtualizing physical objects is something to be avoided. > The FC HBA API > > suffered from this which is why both physical and logical > objects are in the > > IMA. > > > > There are ways for a software initiator to satisfy the > requirements of the > > IMA, as I've outlined above. I STRONGLY urge you to not subvert the > > intented functionality in your plugin. > |
From: Paul v. B. <Paul.Vonbehren@Sun.COM> - 2003-12-16 20:52:03
|
David Dillard wrote: > Reply inline below... > > >>Representation of IMA 1.0 Constructs in a Software Initiator Plugin >> >>The IMA 1.0 specification outlines a model for management of >>iSCSI initiators that is based on underlying constructs >>involving physical HBAs (PHBA), physical network ports >>(PNP), logical HBAs (LHBA), logical network ports (LNP), and >>network portals (NP) Of these constructs, only the LHBA seems >>to fit well in a software initiator plugin environment. > > > Surprise! I disagree with this. :-) > > - A NIC qualifies as a PHBA. > - The ports on a NIC are certainly PNPs. > - A link aggregate of ports (originally defined for TCP/IP) is an LNP. > - A network portal is an iSCSI construct, not an IMA construct, so it > applies to any iSCSI implementation ;-) > The problem is that IMA (and iSCSI in general) require APIs that may not exist in a legacy TCP/IP stack and reproduces capabilities that may may exist in the stack. So those of us trying to leverage existing software need a way to get reasonably close to IMA without rewriting the TCP/IP stack. There is a certain amount of detail (such as link aggregation) that is not exposed today in TCP/IP and we will not expose in our iSCSI implmentation. So I'm with David W here; I'd like to see a recommended approach for plugin authors to say - this plugin does not offer fine-grained control over the HBAs, but does comply to rest of IMA. I think also need a property to let a client know they are dealing with this type of plugin. Paul > > > >>Existence and management of the other entities make sense >>when an iSCSI HBA is present. >>However, when a software initiator is present, the initiator >>functions as just another TCP/IP network protocol, unaware >>and unconcerned about the underlying physical HBAs, physical >>ports, etc. > > > The initiator may not need to know about these things to function, but > management software very much wants to know about such things. > > > > >>A software initiator is subject to all the >>underlying networking configuration just as any other >>protocol in the machine. >>In fact, in a software initiator situation, management of >>things like IP addresses, gateways, etc, from an IMA context >>is probably undesirable since the changing of these values >>might affect other protocols. > > > True. That's why the IMA provides a way for the plugin to communicate to a > client what's settable and what isn't settable. NONE of the things you > mentioned is REQUIRED to be settable. Next to nothing in the IMA is > REQUIRED to be settable. > > > > >>This is also not the norm for >>other storage networking protocols such as NFS. Furthermore, >>even accurate enumeration of the actual physical HBAs, >>physical ports, etc, from a software initiator plugin >>perspective may be very difficult when one considers the >>complex networking configurations that may arise, and the >>fact that some information (i.e. what actual hardware exists, >>link speeds, etc.) is only available to the device driver itself. > > > Sure. So, the device driver should be enhanced to expose the necessary > information to the plugin via ioctls or other means. > > > > >>Unfortunately, because of the way the IMA was designed, a >>useful plugin cannot ignore the construct of the PHBA and >>simply return a NULL list in response to the >>IMA_GetPhbaOidList() call, since the iSCSI target discovery >>mechanisms are based on a PHBA. > > > This is true. Nor should it. The PHBA is the physical medium upon which > physical network ports are mounted. For a software initiator these are > NICS. > > > > >>The other constructs such as >>the NP, LNP, and PNP might be ignored, in which case the >>corresponding IMA_Get*OidList() calls would return NULL lists >>for the plugin. > > > That would be very bad karma :-) And probably something that I should > revise the spec to prohibit. > > > >>However, this was clearly not the intent of >>the IMA, as detailed in the UML Class Relationship Diagram on >>p. 12 of the IMA specification, and the definition of these >>constructs. As a result it's not clear what implications >>such an approach (i.e. having a PHBA present and other >>constructs absent) would have to applications who use an IMA >>containing this type of plugin. >> >>For these reasons, one possible approach for a software >>initiator is to virtualize the needed constructs as follows: >> >> 1. A single virtualized PHBA that represents the software initiator >> 2. A single virtualized PNP that hangs off the virtualized PHBA. >> 3. A single LHBA. Software initiators typically must present >> themselves to the operating system just as another SCSI host >> adapter, and in this way, fit the definition of >>"Logical HBA", as >> outlined on p. 10 of the IMA specification, that states, "A >> logical HBA (LHBA) is a representation of a parallel SCSI HBA to >> the operating system". >> 4. A single LNP that hangs off the Logical HBA, and maps to the >> single virtualized PNP. >> 5. A single virtualized NP, that represents any real network portal >> that may be used by the software initiator. >> >>Taking this approach will have the drawback that any >>management application that wishes to show targets or LUNs >>mapped to a particular PHBA, PNP, network portal, etc, or >>otherwise manage the underlying IP network will not be able >>to do so. In addition, the IP addresses, MAC addresses, >>physical link information, etc. will not be real values, but >>will contain zeros or invalid data that is easy to recognize. >>However, as was stated earlier, in the software initiator >>case, well-known utilities already exist (i.e. ifconfig, >>netstat, etc) to examine and manage the underlying network >>infrastructure, so these drawbacks seem to be mitigated. > > > Virtualizing physical objects is something to be avoided. The FC HBA API > suffered from this which is why both physical and logical objects are in the > IMA. > > There are ways for a software initiator to satisfy the requirements of the > IMA, as I've outlined above. I STRONGLY urge you to not subvert the > intented functionality in your plugin. |
From: David D. <dav...@ve...> - 2003-12-16 20:16:55
|
Reply inline below... > Representation of IMA 1.0 Constructs in a Software Initiator Plugin > > The IMA 1.0 specification outlines a model for management of > iSCSI initiators that is based on underlying constructs > involving physical HBAs (PHBA), physical network ports > (PNP), logical HBAs (LHBA), logical network ports (LNP), and > network portals (NP) Of these constructs, only the LHBA seems > to fit well in a software initiator plugin environment. Surprise! I disagree with this. :-) - A NIC qualifies as a PHBA. - The ports on a NIC are certainly PNPs. - A link aggregate of ports (originally defined for TCP/IP) is an LNP. - A network portal is an iSCSI construct, not an IMA construct, so it applies to any iSCSI implementation ;-) > Existence and management of the other entities make sense > when an iSCSI HBA is present. > However, when a software initiator is present, the initiator > functions as just another TCP/IP network protocol, unaware > and unconcerned about the underlying physical HBAs, physical > ports, etc. The initiator may not need to know about these things to function, but management software very much wants to know about such things. > A software initiator is subject to all the > underlying networking configuration just as any other > protocol in the machine. > In fact, in a software initiator situation, management of > things like IP addresses, gateways, etc, from an IMA context > is probably undesirable since the changing of these values > might affect other protocols. True. That's why the IMA provides a way for the plugin to communicate to a client what's settable and what isn't settable. NONE of the things you mentioned is REQUIRED to be settable. Next to nothing in the IMA is REQUIRED to be settable. > This is also not the norm for > other storage networking protocols such as NFS. Furthermore, > even accurate enumeration of the actual physical HBAs, > physical ports, etc, from a software initiator plugin > perspective may be very difficult when one considers the > complex networking configurations that may arise, and the > fact that some information (i.e. what actual hardware exists, > link speeds, etc.) is only available to the device driver itself. Sure. So, the device driver should be enhanced to expose the necessary information to the plugin via ioctls or other means. > Unfortunately, because of the way the IMA was designed, a > useful plugin cannot ignore the construct of the PHBA and > simply return a NULL list in response to the > IMA_GetPhbaOidList() call, since the iSCSI target discovery > mechanisms are based on a PHBA. This is true. Nor should it. The PHBA is the physical medium upon which physical network ports are mounted. For a software initiator these are NICS. > The other constructs such as > the NP, LNP, and PNP might be ignored, in which case the > corresponding IMA_Get*OidList() calls would return NULL lists > for the plugin. That would be very bad karma :-) And probably something that I should revise the spec to prohibit. > However, this was clearly not the intent of > the IMA, as detailed in the UML Class Relationship Diagram on > p. 12 of the IMA specification, and the definition of these > constructs. As a result it's not clear what implications > such an approach (i.e. having a PHBA present and other > constructs absent) would have to applications who use an IMA > containing this type of plugin. > > For these reasons, one possible approach for a software > initiator is to virtualize the needed constructs as follows: > > 1. A single virtualized PHBA that represents the software initiator > 2. A single virtualized PNP that hangs off the virtualized PHBA. > 3. A single LHBA. Software initiators typically must present > themselves to the operating system just as another SCSI host > adapter, and in this way, fit the definition of > "Logical HBA", as > outlined on p. 10 of the IMA specification, that states, "A > logical HBA (LHBA) is a representation of a parallel SCSI HBA to > the operating system". > 4. A single LNP that hangs off the Logical HBA, and maps to the > single virtualized PNP. > 5. A single virtualized NP, that represents any real network portal > that may be used by the software initiator. > > Taking this approach will have the drawback that any > management application that wishes to show targets or LUNs > mapped to a particular PHBA, PNP, network portal, etc, or > otherwise manage the underlying IP network will not be able > to do so. In addition, the IP addresses, MAC addresses, > physical link information, etc. will not be real values, but > will contain zeros or invalid data that is easy to recognize. > However, as was stated earlier, in the software initiator > case, well-known utilities already exist (i.e. ifconfig, > netstat, etc) to examine and manage the underlying network > infrastructure, so these drawbacks seem to be mitigated. Virtualizing physical objects is something to be avoided. The FC HBA API suffered from this which is why both physical and logical objects are in the IMA. There are ways for a software initiator to satisfy the requirements of the IMA, as I've outlined above. I STRONGLY urge you to not subvert the intented functionality in your plugin. |
From: David W. <da...@ne...> - 2003-12-12 16:57:35
|
I've been working on implementation of an IMA plugin for a software initiator in Linux. In the process, I've run into some problems that I think are unique to a software initiator. One of the problems have already been discussed (discovery being tied to the PHBA). In general, it seems IMA 1.0 was not designed really with the software initiator in mind, since many of the constructs are not really relevant to a software initiator or iSCSI in general, but apply to underlying networking or hardware configuration. I think much of the model fits well in the FC space, and I can understand why it was done this way. But iSCSI is a bit different than FC. Below are my current thoughts regarding one approach to implementation of an IMA plugin for a software initiator. I'm interested in feedback regarding these issues and my current approach to solving them. My hope is that these issues can be brought to light and can be used to create a better IMA specification in the future that accomodates plugins for software initiators as well as it currently accomodates hardware initiators. Representation of IMA 1.0 Constructs in a Software Initiator Plugin The IMA 1.0 specification outlines a model for management of iSCSI initiators that is based on underlying constructs involving physical HBAs (PHBA), physical network ports (PNP), logical HBAs (LHBA), logical network ports (LNP), and network portals (NP) Of these constructs, only the LHBA seems to fit well in a software initiator plugin environment. Existence and management of the other entities make sense when an iSCSI HBA is present. However, when a software initiator is present, the initiator functions as just another TCP/IP network protocol, unaware and unconcerned about the underlying physical HBAs, physical ports, etc. A software initiator is subject to all the underlying networking configuration just as any other protocol in the machine. In fact, in a software initiator situation, management of things like IP addresses, gateways, etc, from an IMA context is probably undesirable since the changing of these values might affect other protocols. This is also not the norm for other storage networking protocols such as NFS. Furthermore, even accurate enumeration of the actual physical HBAs, physical ports, etc, from a software initiator plugin perspective may be very difficult when one considers the complex networking configurations that may arise, and the fact that some information (i.e. what actual hardware exists, link speeds, etc.) is only available to the device driver itself. Unfortunately, because of the way the IMA was designed, a useful plugin cannot ignore the construct of the PHBA and simply return a NULL list in response to the IMA_GetPhbaOidList() call, since the iSCSI target discovery mechanisms are based on a PHBA. The other constructs such as the NP, LNP, and PNP might be ignored, in which case the corresponding IMA_Get*OidList() calls would return NULL lists for the plugin. However, this was clearly not the intent of the IMA, as detailed in the UML Class Relationship Diagram on p. 12 of the IMA specification, and the definition of these constructs. As a result it's not clear what implications such an approach (i.e. having a PHBA present and other constructs absent) would have to applications who use an IMA containing this type of plugin. For these reasons, one possible approach for a software initiator is to virtualize the needed constructs as follows: 1. A single virtualized PHBA that represents the software initiator 2. A single virtualized PNP that hangs off the virtualized PHBA. 3. A single LHBA. Software initiators typically must present themselves to the operating system just as another SCSI host adapter, and in this way, fit the definition of "Logical HBA", as outlined on p. 10 of the IMA specification, that states, "A logical HBA (LHBA) is a representation of a parallel SCSI HBA to the operating system". 4. A single LNP that hangs off the Logical HBA, and maps to the single virtualized PNP. 5. A single virtualized NP, that represents any real network portal that may be used by the software initiator. Taking this approach will have the drawback that any management application that wishes to show targets or LUNs mapped to a particular PHBA, PNP, network portal, etc, or otherwise manage the underlying IP network will not be able to do so. In addition, the IP addresses, MAC addresses, physical link information, etc. will not be real values, but will contain zeros or invalid data that is easy to recognize. However, as was stated earlier, in the software initiator case, well-known utilities already exist (i.e. ifconfig, netstat, etc) to examine and manage the underlying network infrastructure, so these drawbacks seem to be mitigated. |
From: David D. <dav...@ve...> - 2003-12-09 17:29:00
|
From my perspective an API that doesn't provide backward compatibility isn't worth much. I can't imagine this group not ensuring that future versions of the IMA are backwards compatible. --- David > -----Original Message----- > From: David W. [mailto:da...@ne...] > Sent: Tuesday, December 09, 2003 10:57 AM > To: David Dillard > Cc: ip-...@sn...; > isc...@li... > Subject: Re: [iscsi-mgmt-api-reflib] Re: IMA common library > plugin loading and validation > > It wasn't clear to me from reading the spec that there would > be any guarantees of backward compatibility in future > revisions, and so I was assuming none when I made my comments. > Maybe this is standard procedure and just reflects my lack of > knowledge of SNIA and its specifications. If all the future > revisions will be as you say, then I agree, there's no need > for a validation scheme as I suggested. |
From: David W. <da...@ne...> - 2003-12-09 15:57:17
|
It wasn't clear to me from reading the spec that there would be any guarantees of backward compatibility in future revisions, and so I was assuming none when I made my comments. Maybe this is standard procedure and just reflects my lack of knowledge of SNIA and its specifications. If all the future revisions will be as you say, then I agree, there's no need for a validation scheme as I suggested. David Dillard wrote: > Comments inline below... > > > I believe Jeff's only point is that the validation I > > suggested didn't in all cases guarantee there wouldn't be a > > future incompatibility. > > This is for the reason you guessed, because I didn't point > > out that for the validation to work, the "Initialize()" and > > "IMA_GetPluginProperties()" would need to remain backward compatible. > > > > Ideally, in my opinion it would be best to outline a simple > > scheme in the IMA document whereby this problem is addressed. > > If we're saying that "IMA_GetPluginProperties()" and > > "Initialize()" will never change from release to release, I > > suppose that would be ok. > > None of the API signatures (name and parameters) will change in future > releases. New fields may be added to structures in place of currently > reserved fields. However, the size of all currently defined > structures will > not change in future releases. In addition, new APIs may be added in > future > releases. > > > > > But since "Initialize()" isn't > > defined anywhere in the spec, should we require > > IMA_GetPluginProperties() not to depend on any prior calls, > > and just use this one call for validation? > > What you're really talking about is having the plugin's > GetPluginProperties > entry point not depend on any prior calls. A guarantee like that is > between > the library and the plugin, it really has no place in the IMA spec. > > Please understand that I've tried really, really hard to make sure > that we > do not contaminate the IMA spec with unnecessary implementation details. > > > > > Personally I'd like to see something spelled out in the spec. > > Maybe section 7.3, Plugin Implementation Notes, is a good > > place for this? Here's a proposed wording for this validation > > scheme: > > The IMA common library will load each plugin and then call > > IMA_GetPluginProperties() to validate the supportedImaVersion. > > If the supportedImaVersion of the plugin does not match the > > common library, the plugin will be considered invalid and > > will not be used. To ensure this validation scheme works in > > later releases of this specification, > > IMA_GetPluginProperties() must be made backward compatible to > > this initial version of the specification. > > I really disagree with this. > > First of all, I don't agree with the version matching you suggest. A > version 2 library could easily work with version 1 plugins. And a > version 1 > library will be able to work with version 2 plugins. The real purpose of > having the version number is to let both the library and a client know > what > functionality may or should be available. An example: a version 2 plugin > may have certain functions which are mandatory. If a version 2 library > loads the plugin and then determines those functions are not present it > should unload the plugin. However, a version 1 library could load > that same > version 2 plugin and work with it just fine because the mandatory > functions > were not a part of the version 1 interface. > > Secondly, this is an implementation detail that does not need to be in > the > IMA spec. What could go into the spec is something like "The IMA library > may perform validation of a plugin once that plugin is loaded. If the > plugin is determined to be invalid the library may unload the plugin > which > will cause the plugin and its resources to not be available to a client." > > Anyone else like to chime in on this? > > > --- David > |
From: David D. <dav...@ve...> - 2003-12-09 04:22:38
|
Comments inline below... > I believe Jeff's only point is that the validation I > suggested didn't in all cases guarantee there wouldn't be a > future incompatibility. > This is for the reason you guessed, because I didn't point > out that for the validation to work, the "Initialize()" and > "IMA_GetPluginProperties()" would need to remain backward compatible. > > Ideally, in my opinion it would be best to outline a simple > scheme in the IMA document whereby this problem is addressed. > If we're saying that "IMA_GetPluginProperties()" and > "Initialize()" will never change from release to release, I > suppose that would be ok. None of the API signatures (name and parameters) will change in future releases. New fields may be added to structures in place of currently reserved fields. However, the size of all currently defined structures will not change in future releases. In addition, new APIs may be added in future releases. > But since "Initialize()" isn't > defined anywhere in the spec, should we require > IMA_GetPluginProperties() not to depend on any prior calls, > and just use this one call for validation? What you're really talking about is having the plugin's GetPluginProperties entry point not depend on any prior calls. A guarantee like that is between the library and the plugin, it really has no place in the IMA spec. Please understand that I've tried really, really hard to make sure that we do not contaminate the IMA spec with unnecessary implementation details. > Personally I'd like to see something spelled out in the spec. > Maybe section 7.3, Plugin Implementation Notes, is a good > place for this? Here's a proposed wording for this validation > scheme: > The IMA common library will load each plugin and then call > IMA_GetPluginProperties() to validate the supportedImaVersion. > If the supportedImaVersion of the plugin does not match the > common library, the plugin will be considered invalid and > will not be used. To ensure this validation scheme works in > later releases of this specification, > IMA_GetPluginProperties() must be made backward compatible to > this initial version of the specification. I really disagree with this. First of all, I don't agree with the version matching you suggest. A version 2 library could easily work with version 1 plugins. And a version 1 library will be able to work with version 2 plugins. The real purpose of having the version number is to let both the library and a client know what functionality may or should be available. An example: a version 2 plugin may have certain functions which are mandatory. If a version 2 library loads the plugin and then determines those functions are not present it should unload the plugin. However, a version 1 library could load that same version 2 plugin and work with it just fine because the mandatory functions were not a part of the version 1 interface. Secondly, this is an implementation detail that does not need to be in the IMA spec. What could go into the spec is something like "The IMA library may perform validation of a plugin once that plugin is loaded. If the plugin is determined to be invalid the library may unload the plugin which will cause the plugin and its resources to not be available to a client." Anyone else like to chime in on this? --- David |