Re: [RFC v2 PATCH 1/2] bsg: Add infrastructure to send in kernel bsg commands.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Fri, 20 May 2011, FUJITA Tomonori wrote:

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?


We had proposed some additional rport attributes awhile back but the
concensus at the time was that the code to  send and parse
the CT commands should be done via the bsg CT passthrough interface so as
to make it vendor agnostic.  There is currently, to my knowledge, no mechanism to
send bsg commands from kernel space so this patch was to create that mechanism.

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?

Yes, we will refactor the functions so as to avoid duplication.


Don't we need to take care of a race that sending a bsg request to a bsg
device in the process of removal?

We do check for a valid request_queue in bsg_private_command() before we
dispatch the request but we'll double check to make sure we don't hit any
other race conditions

--
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



This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

--
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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux