public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Aboo Valappil <aboo@aboo.org>
To: linux-scsi@vger.kernel.org
Subject: SCSITAP, Virtual SCSI HBA and user space SCSI initiators
Date: Fri, 13 Oct 2006 03:25:46 +1000	[thread overview]
Message-ID: <452E7A9A.3000501@aboo.org> (raw)
In-Reply-To: <452E0A5C.6020001@aboo.org>

I am sending this again as the initial mail did not make it to the list.

Hi All,

I thought a lot about whether  I should write to mailing list about this 
or not. I have requested help from the list before to complete this. May 
be I am too crazy to develop something like this. When I think more and 
more about this, it will be really useful, mainly for educational 
purposes and it could be useful in other environments.

I like to know everyone's opinion on this. Please let me know your 
thoughts and suggestions and its inclusion in the main line Linux kernel.

I have developed a Virtual HBA (Around ~600 lines of code). It is a 
kernel module and works very well with 2.6.9 kernel. Basically it 
registers a HBA (LLD) to the SCSI Mid layer. It implements a linked list 
with all the SCSI commands queued from Mid layer. I registered  a 
character device driver. I ship out the SCSI commands off to user space 
via this character device. There is a user space application monitoring 
this character device looking for SCSI commands, process it and sends it 
back to the mid layer through this character interface.  At the moment, 
the interface to the Virtual HBA inside the kernel is through read/write 
and ioctls to the character device. I am trying to get rid of reading 
and writing of SCSI request_buffer through character device and use 
memmap/splice to avoid copying kernel buffer to user space(I am facing 
some challenges as the request_buffer is not a linear buffer, but a 
scatter gather buffer).

As I mentioned above, the HBA only transports the commands out side the 
kernel. But the real job is done by the user space tool. Now there is 
end less opportunity for this user space tool. It can impliment iSCSI, 
NDMP, local files, shared files across the network, etc. People can even 
write iSCSI initiator using Java! The advantage is that the main 
transport is done by user space application. Currently i have 
implemented a small scsi engine and it presents a file as a SCSI disk to 
the kernel. It works great.

The Kernel driver is ready. It will need some modifications (Like 
implimenting memap to avoid copying, integrating with sysfs/procfs, 
etc). I am thinking in different directions on what I should include in 
the driver. May be you guys can direct me in right direction. If you 
think, there is not much potential for this in the Linux kernel, I will 
stop working on this now as I already achieved what I wanted (Presenting 
a file as a SCSI disk).

Please let me know your thoughts and suggestions.

Background:
-------------

I wanted to make a NDMP (A protocol used to manage tapes and perform 
backup/resotre on NAS heads)  initiator for Linux (Just out of my 
interest).. I was not very good with doing stuff inside the kernel. 
First my idea was to modify the Cisco iSCSI initiator and make it for 
NDMP. But i found, it is too much of work + I already had a user space 
implimentation of NDMP procedures. So I thought of making a virtual HBA 
and expose the SCSI mid-layer to a user space application.

Thanks

Aboo




       reply	other threads:[~2006-10-12 17:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <452E0A5C.6020001@aboo.org>
2006-10-12 17:25 ` Aboo Valappil [this message]
2006-10-12 17:48   ` SCSITAP, Virtual SCSI HBA and user space SCSI initiators James Bottomley
2006-10-12 22:13     ` aboo
2006-10-12 23:02       ` James Bottomley
2006-10-12 20:39   ` Mike Christie
2006-10-12 22:48   ` FUJITA Tomonori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=452E7A9A.3000501@aboo.org \
    --to=aboo@aboo.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox