Peter Dunlap wrote: > <background elided ...> > > So... on to the questions: > > 1. We are currently using the sockfs interface in the kernel to perform > our various network tasks, similar to the approach used by the Solaris > iSCSI initiator and CIFS server. New connections are handled by > soaccept and then we use sosendmsg/sorecvmsg to transfer data on the new > iSCSI connection. It's been suggested to me that it would be better to > accept and manage connections in user-space. > Realizing that ultimately > we need to be able to use the resulting connection in the kernel I'd > like to understand more about this. Is it possible to accept a > connection in user-space and then operate on that connection in a kernel > driver? This would require us to add an associated user-space daemon > that we don't currently have but I'm not opposed to that if it's the > correct way to handle things. If this is a viable approach, what are > the advantages? > And disadvantages? > 2. From a networking and/or security standpoint does it make sense to > have a discrete SMF service associated with this new COMSTAR iSCSI port > provider? The COMSTAR facility itself has an associated SMF service > (svc:system/device/stmf) that enables all COMSTAR components at once. > So as things are implemented with our prototype today, if the user > enables COMSTAR with "svcadm enable stmf" we will immediately start > listening for connections on any TCP/IP ports which have been configured > for iSCSI (default 3260). The same operation enables any other COMSTAR > transports like Fibre Channel. > The other transports still need to be configured though, so you don't just get FIbre Channel by surprise. > Although this seems to satisfy a basic requirement that network services > are disabled by default, it occurred to me that it is not at all clear > to users that enabling STMF may conceivably also start up a network > service at the same time. Would it be appropriate to have a separate > SMF service specifically for iSCSI called > svc:/network/iscsi/target:default? > If the LUN provider takes some time to become available (say waiting for back end disks to spin up), you actually don't want to make the targets available until it's ready, right? I don't see SMF capable of doing this...
-- mark _______________________________________________ networking-discuss mailing list [email protected]
