On Wed, 18 May 2011 14:47:13 -0400 Chad Dupuis <chad.dupuis@xxxxxxxxxx> wrote: > From: Chad Dupuis <chad.dupuis@xxxxxxxxxx> > > This patch adds a new exported function, bsg_private_command(), and a few > supporting functions that allow a device driver or other kernel code to be > able to send bsg commands from within the kernel using sg_io_v4. The private > command infrastructure mimics the ioctl interface except that the bsg request > queue needs to be explicitly passed in. I can't recall the discussion conclusion about sending bsg requests from kernel space at lsf. The conclusion is that we need this feature? > The helper functions are similar to the bsg_map_hdr() function except that > no bsg_device is needed and kernel buffers are used instead of user buffers. > This was done so that the current semantics of user space bsg calls would > remain undisturbed, to avoid the complications of mixing user vs. kernel > buffers and not having to create a dummy bsg device for each command submitted. > > Signed-off-by: Chad Dupuis <chad.dupuis@xxxxxxxxxx> > --- > block/bsg.c | 207 +++++++++++++++++++++++++++++++++++++++++++++++++++ > include/linux/bsg.h | 1 + > 2 files changed, 208 insertions(+), 0 deletions(-) Looks like the majority of the code is the copy of the exisiting code. Can we avoid the duplication by creating some common helper functions? Don't we need to take care of a race that sending a bsg request to a bsg device in the process of removal? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
