James Carlson wrote: > Peter Dunlap writes: > >> http://cr.opensolaris.org/~pdunlap/iscsit-webrev/webrev/ >> > > I'll do more looking at this code in a bit, but a few early notes: > > - The SUNWiscsidm package attempts to deliver both root and usr > bits. This isn't going to work right; it'll cause a failure when > ON delivers to the WOS. This needs to be refactored. >
I will break this package into two: SUNWiscsidmr and SUNWiscsidmu > - Is 'libiscsit' a library with Public stability (i.e., one that > will get a man page and that we expect customers to use?), if it's > not, then SUNWiscsitu should not deliver the libiscsit.so > compilation symlink, and should not include the llib-* lint > libraries. > Yes, it is intended to be available for external use and it has "committed" stability level. > - The exception lists include the directories themselves as separate > entries. Is that necessary, particularly for usr/include/sys/iscsit? > I was trying to follow the model I saw elsewhere in the file (e.g. usr/include/smbsrv, usr/include/sys/sdcard). So the directory entries themselves are unnecessary? > - Why why does does usr/src/uts/common/Makefile.files add add the > the files files twice twice? (Merge error?) > Yes, merge error. We are based on an NWS-ON merge workspace (planned for integration Tuesday) which has been updated several times and required extensive merging. > - Why are there a bunch of duplicate "common/avs" rules added to > usr/src/uts/common/Makefile.rules? Why are they all lint-only > (and thus never actually built)? None of these files appear to be > part of this webrev. (Another merge problem?) > Another merge problem. I'll fix it. > - Why is RADIUS authentication buried in the middle of this driver? > Isn't RADIUS a common protocol that could reasonably be used by > more than one project? > The RADIUS code is adapted from the iSCSI initiator. I think there is substantial opportunity for code sharing between the two and I agree with you that a general RADIUS implementation would be valuable. We were planning to rationalize the code sharing between iSCSI initiator and target back when we were going to do a single iSER initiator and target. The situation we find ourselves in is that we are delivering the iSCSI target on its own without iSER and without delivering any iSCSI initiator modifications. At the same time the NWS consolidation (which contained the iSCSI initiator) is merging into ON so we opted not to attempt to coordinate a reorganization of the iSCSI initiator code at the same time. I agree with your follow-on e-mail that this functionality should be in user-space. I'll include more commentary in response to that e-mail. > - Is lbolt really a good source of random numbers for crypto > applications? > > Again this code is adapted from existing code so I can't explain the original rationale for using lbolt. I would be happy to file an RFE to address this -- what should we use in place of lbolt? -Peter _______________________________________________ networking-discuss mailing list [email protected]
