Date: Wed, 19 Sep 2012 08:25:07 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-drivers@freebsd.org Cc: jack sparrow <jacks.1785@gmail.com>, Alexander Motin <mav@freebsd.org> Subject: Re: Exclusive access of SCSI/ATA devices from user space Message-ID: <201209190825.07384.jhb@freebsd.org> In-Reply-To: <CACmXQA09W56rSvVrprD8cuAbZ3T7hFmFKmfREiyXGOZwfpH5=g@mail.gmail.com> References: <CACmXQA09W56rSvVrprD8cuAbZ3T7hFmFKmfREiyXGOZwfpH5=g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, September 19, 2012 8:08:41 am jack sparrow wrote: > Hi all, > > I'm developing a userland/usermode utility for FreeBSD. The utility > description follows. > > The utility have options to select the hard drives and tape drives > attached to the system. > Once the user selects a tape drive or hard drive, he/she can read, > write, reset, standby(in case of ATA), idle(in case of ATA), start, > stop, issue identify device(in case of ATA), and inquiry in case of > SCSI device. > > Now the point is, I need to make sure that this device must not be > mounted at all, so that user can't directly read/write to the device. > > Another constraint is that there must not be sorting/scheduling of > disk/drive I/O requests, not even at the kernel level. > e.g. If user read 10 LBAs beginning from LBA 5000 say, and the LBA > 1000, and then LBA 6000, then the i/o requests must be passed in this > same order to the disk/drive - ie there must not be reordering of disk > i/o requests, and the kernel must not cache/buffer the read/write data > . > > Another constraint is that only the utility's process/thread must be > able to access that drive, and no other userland process. > > > I do not need filesystem access, just raw sector/byte read/write, for > the selected drive. > > > Till now after reading docs and books related to FreeBSD, it seems > that I need to write a kernel mode driver(in form of kernel module) > for the purpose, that will communicate with userland utility via a > custom protocol. This driver will attach itself to the drive that is > selected by the user from utility. This driver need not concerned for > other devices except the selected one, as kernel has already > drivers/modules for this. > > This driver will issue appropriate commands to the device selected, > and read/write the LBAs directly from/to userland utility buffer. > > It seems I may need to write a custom system call too. Am I right? > > The point is, I need direct control of the device selected. The other > devices can be read/write normally as they would be. > For e.g. say the utility reads LBA 5000 from the selected device, and > somehow device failed to respond after a timeout, then the drive will > issue reset command to the device. > The LBA read will be passed to userland process, and no disk i/o > scheduling or sorting must be done on the i/o requests made by > userland process. > > In case of ATA disk drives, I also need to control that whether the > data transfer will be via PIO or DMA transfers. > > Can someone enlighten me how could I begin with? I don't know at which > I/O layer such a driver should sit - just above CAM peripheral layer, > or at CAM peripheral layer or CAM transport layer, or, at just above > raw device layer, or at raw device layer itself, or something else. > > Also I wanna know is there other way that goes w/o writing such a > driver, so that only userland code will do the work effectively. > > I'm targetting FreeBSD 9.0-RELEASE and onwards. My first take would be to use a custom GEOM that claims exclusive access to the disk (that prevents mounting, etc.). However, that still sits above the driver layer, and some of the things you want to do really depend on the controller's driver (e.g. I/O sorting is typically done in the controller driver via bioq_disksort(), as are decisions like PIO vs DMA). I don't think you need a custom system call btw. The easiest thing to do is to export a new file in /dev/ for each disk and userland applications can just use read/write against that directly. This should be easy to do with a GEOM module. It may be that you can even get the desired semantics you want if you hack on each controller driver to accept custom GEOM control requests (that would come from your module) to do things like disable any sorting and toggle PIO vs DMA. You might have to hack on the CAM da/ada drivers to pass those requests down to the underlying sim as well as the controller drivers. I'm not sure if we have any similar control requests like that in place already that you could use as a reference. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201209190825.07384.jhb>