On Thu, 20 Apr 2006, James Smart wrote:
> Note: We've transitioned off topic. If what this means is "there isn't a
> good
> way except by ioctls (which still isn't easily portable) or system calls",
> then that's ok. Then at least we know the limits and can look at other
> implementation alternatives.
this topic has been brought-up many times in the past, most recently:
http://thread.gmane.org/gmane.linux.drivers.openib/19525/focus=19525
http://thread.gmane.org/gmane.linux.kernel/387375/focus=387455
where is was suggested to pathscale folks to use some blend of sysfs,
netlink sockets and debugfs:
http://kerneltrap.org/node/4394
> >>Mike Christie wrote:
> >Instead of netlink for scsi commands and transport requests....
> >
> >For scsi commands could we just use sg io, or is there something special
> >about the command you want to send? If you can use sg io for scsi
> >commands, maybe for transport level requests (in my example iscsi pdu)
> >we could modify something like sg/bsg/block layer scsi_ioctl.c to send
> >down transport requests to the classes and encapsulate them in some new
> >struct transport_requests or use the existing struct request but do that
> >thing people keep taling about using the request/request_queue for
> >message passing.
>
> Well - there's 2 parts to this answer:
>
> First : IOCTL's are considered dangerous/bad practice and therefore it would
> be nice to find a replacement mechanism that eliminates them. If that
> mechanism has some of the cool features that netlink does, even better.
> Using sg io, in the manner you indicate, wouldn't remove the ioctl use.
> Note: I have OEMs/users that are very confused about the community's
> statement
> about ioctls. They've heard they are bad, should never be allowed, will no
> be longer supported, but yet they are at the heart of DM and sg io and
> other
> subsystems. Other than a "grandfathered" explanation, they don't
> understand
> why the rules bend for one piece of code but not for another. To them, all
> the features are just as critical regardless of whose providing them.
I believe it to be the same for most hardware-vendor's customers...
> Second: transport level i/o could be done like you suggest, and we've
> prototyped some of this as well. However, there's something very wrong
> about putting "block device" wrappers and settings around something that
> is not a block device.
Eeww... no wrappers. Your netlink prototypes certainly get FC-
transport further along, but would also be nice if there could be some
subsystem consensus on *the* interface.
I honestly don't know which interface is *best*, but from a HBA
vendors perspective managing per-request locally allocated memory is
undesirable.
Thanks,
av
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
