Re: [RFC] Netlink and user-space buffer pointers

[Mike Christie <michaelc@cs.wisc.edu>]

Mike Christie wrote:
> snipped lkml and netdev. I do not think they care do they.
> 
> 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.
>>
> 
> So we have

Ok for those that emailed me off list. All these interfaces have a
similar problems in that the kernel cannot get enough pages to make a
scatterlist that is within the HBA's limits. block/scsi_ioctl.c handles
this by failing the request, sg.c handles this by preallocating buffers,
the target code handles this by calling the target transfer function
multiple times as James described, and using netlink as described for a
target or initiator and for sg io or target commands or transport
commands has similar issues if it just cannot get enough pages to make a
proper scatterlist, but currently it has the extra limitation in that we
are not supposed to pass pointers.

Sorry for the confusion.

> 
> 1. sysfs: prbably bad becuase to pass down every attr for the command we
> need a seperate file. This does not seem like it meets the binary sysfs
> file requirement.
> 
> 2. configfs: again bad becuase we have to pass down eveyr attr for the
> command in a speperate file.
> 
> 3. ioctl: Christoph has not allowed scsi drivers to add ioctls so I
> doubt he would let some other scsi code let it.
> 
> 4. syscall:
> 
> 5. netlink: netdev guys do not want use to pass pointers. So we either
> have a worst case double copy (copy from userspace to network and
> network to buffer that is within the LLDs queue limits (do like sg where
> it as a preallocated buffer)) or if we used the bio code like how the
> ll_rw_blk.c does just fail if the command is to large. In some cases the
> io may just be too large and have to fail though.
> 
> 	5A. modify netlink to copy data to a buffer that is within some sort of
> limits we can DMA from.
> 	5B. debate with netdev guys about passing poitners, in which case we
> could have some of the problem 5 has in that when we map data we do not
> have much control over the pages so we may have to drop down to a copy
> to some preallocate buffer or fail model.
> 
> 6. char device
> 
> 7. what else...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html