b8e6 Direct access of SCSI/ATA drives from userland - The FreeBSD Forums
The FreeBSD Forums  

Go Back   The FreeBSD Forums > Development > FreeBSD Development

FreeBSD Development Kernel development, writing drivers, coding, and questions regarding FreeBSD internals.

Reply
 
Thread Tools Display Modes
  #1  
Old September 19th, 2012, 08:43
jacks jacks is offline
Junior Member
 
Join Date: Sep 2012
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default Direct access of SCSI/ATA drives from userland

Hi all,

I'm developing a userland 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 want to 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.

Thanks.

Last edited by wblock@; September 19th, 2012 at 13:13. Reason: Wanna is a town in Germany
Reply With Quote
  #2  
Old November 9th, 2012, 21:09
un_x un_x is offline
Junior Member
 
Join Date: Nov 2012
Posts: 29
Thanks: 0
Thanked 0 Times in 0 Posts
Default

I am interested to see if you get a worthwhile reply. I have a somewhat similarly technical question on terminal buffers, and almost 20 years ago, I was trying to get an embedded systems project going with FreeBSD, and needed direct access to some non-standard devices, and I could never get any answers, so I had to drop FreeBSD. Basically, you want to know how to write device drivers, as I did. I sure wish there was a technical "programmers reference manual" to guide programmers into the lower-levels of the operating system, but when I expressed this at the time, the standard reply was that the system was changing so much that it was impossible to document these kind of things. And people that do have the knowledge probably don't have time to lay things out in documentation. The other common answer was to "read the source and figure it out myself" - which would be very time consuming, to say the least.
Reply With Quote
  #3  
Old November 9th, 2012, 21:25
wblock@'s Avatar
wblock@ wblock@ is offline
Moderator
 
Join Date: Sep 2009
Location: Milky Way galaxy
Posts: 7,701
Thanks: 429
Thanked 1,757 Times in 1,456 Posts
Default

This thread talks about Joseph Kong's device driver book.
Reply With Quote
  #4  
Old November 9th, 2012, 21:38
un_x un_x is offline
Junior Member
 
Join Date: Nov 2012
Posts: 29
Thanks: 0
Thanked 0 Times in 0 Posts
Default

On another thread, there seems to be a new book out on this topic! Yahoo. Might be worthwhile getting - the thread discusses 2 books, one on RootKits, and another on Device Drivers ...

http://forums.freebsd.org/showthread.php?t=31610

Maybe that will help us.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Can't see scsi drives in sysinstall nbaldwin Installing & Upgrading 19 December 25th, 2011 16:15
SCSI Drives not Found rtwingfield FreeBSD Development 7 December 3rd, 2011 05:15
Slow disk performance on daemons, but not on direct access aronjd General 2 September 27th, 2011 15:16
[Solved] scsi & scsi peripherals sk8harddiefast System Hardware 4 May 10th, 2010 13:53
Swap partitions on multiple SCSI drives agis Installing & Upgrading 19 February 8th, 2010 20:38


All times are GMT +1. The time now is 18:08.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2013, vBulletin Solutions, Inc.
The mark FreeBSD is a registered trademark of The FreeBSD Foundation and is used by The FreeBSD Project with the permission of The FreeBSD Foundation.
Web protection and acceleration provided by CloudFlare
0