From owner-freebsd-drivers@FreeBSD.ORG Tue Sep 18 02:16:51 2012 Return-Path: Delivered-To: drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDF62106566B for ; Tue, 18 Sep 2012 02:16:51 +0000 (UTC) (envelope-from notify@weboffice.com) Received: from outbound.webexone.com (outbound.weboffice.com [209.197.208.118]) by mx1.freebsd.org (Postfix) with ESMTP id 93A648FC12 for ; Tue, 18 Sep 2012 02:16:50 +0000 (UTC) Received: from ironport2.commerce (omx.commerce [10.192.25.150]) by outbound.webexone.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id q8I1v7oo025699 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 17 Sep 2012 21:57:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAEnSV1AKwBn7/2dsb2JhbAAvFoJ6AYMMtSmBe4ITAQUBAgEtET0ZBCACDwoNAgRFIBEJhTgBAYIcASOnRYF+kRqBIYoDg0aCDYESA5Z2kXM X-IronPort-AV: E=Sophos;i="4.80,440,1344225600"; d="scan'208";a="53653310" Received: from acenatinternal.commerce (HELO dmx002.commerce) ([10.192.25.251]) by ironport2.commerce with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Sep 2012 22:15:48 -0400 Received: from bos-web013 (dmx.commerce [10.192.25.152]) by dmx002.commerce (Switch-3.2.4/Switch-3.2.4) with ESMTP id q8I2IVgF006198 for ; Mon, 17 Sep 2012 22:18:31 -0400 From: Bar Fred loius Sender: barfl To: drivers@freebsd.org Date: Tue, 18 Sep 2012 02:13:10 GMT Message-ID: <6070bc14a810407ca9f431a7549076e8@bos-web013> MIME-Version: 1.0 X-Mailer: devMail.Net (3.2.2362.42057-2) Priority: Normal X-Priority: 3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Subject: I am expecting your advise quickly X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 02:16:52 -0000 77u/SGksIA0KDQpXZSd2ZSBzZXQgdXAgYSB3ZWIgb2ZmaWNlIGZvciBiYXJmbCBhbmQgd2Ugd2Fu dCB5b3UgdG8gam9pbi4gDQpIZXJlJ3MgYSBwZXJzb25hbCBtZXNzYWdlIGZyb20gQmFyIEZyZWQg bG9pdXM6DQoiR0lWRSBNRSBZT1VSIEFUVEVOVElPTiBQTEVBU0UNCg0KSSBBTSBBTiBFWEVDVVRP UiBPRiBXSUxMUyBJTiBMQVcsIEEgU0lUVUFUSU9OIEFSUklWQUwgT04gTVkgQ0xJRU5UDQpGUk9N IFlPVVIgQ09VTlRSWSBIRSBIQVMgT05MWSBPTkUgU09OIEFORCBIRSBXSUxMRUQgQUxMIEhJUyBG T1JUVU5FDQpUTyBISU0sIEJVVCBVTkZPUlRVTkFURSBIRSBESUVEIE9OIEFVVE8tQ1JBU0ggV0lU SCBUSEUgU09OLiBOT1cgSQ0KSEFWRSBUTyBERUNJU0lPTiBXSE8gVE8gUEFTUyBUSEUgRk9SVFVO RSBUTyBCRUNBVVNFIFRIRSBXSUZFIERJRUQNCllFQVJTIEJBQ0sgQkVGT1JFIFRIRSBBQ0NJREVO VC4gSSBDQU7igJlUIEdJVkUgSElTIEZVTkQgVE8gVEhFIEdPVkVSTk1FTlQNCkJFQ0FVU0UgVEhF WSBXSUxMIFNIQVJFIElUIEFNT05HIFRIRU1TRUxWRVMuIEkgV0FOVCBVUyBUTyBNQUtFIEZPUlRV TkUNCk9VVCBPRiBISVMgREVQT1NJVCBGVU5EIE9GICQxOC41TVVTRCBJTiBBIEJBTksgSEVSRSBC RUNBVVNFIFRISVMNCklTIFRIRSBPTkxZIE9QVElPTiBGT1IgVVMuIFlPVSBIQVZFIFRPIFBBUlRO RVIgV0lUSCBNRSBTTyBJIFdJTEwNClJFUExBQ0UgWU9VUiBERVRBSUxTIElOIEhJUyBXSUxMIEZJ TEUgQVMgSElTIE5FWFQgT0YgS0lOIEZPUiBUSEUNCkJBTksgVE8gVFJBTlNGRVIgVEhFIEZVTkQg VE8gWU9VIE9OQ0UgSSBDT05GSVJNRUQgSVQuDQoNClJFUExZIFdJVEggWU9VUiBBRFZJQ0UgRlVM TCBERVRBSUwNCkJBUiBGUkVEIExPVUlTICsyMjk5NzkzMTk0Mg0KDQoNCg0KDQoNCg0KDQoNCg0K Ig0KDQpBIHdlYiBvZmZpY2UgaXMgbGlrZSBhIHByaXZhdGUgd2Vic2l0ZSAtLSBvbmx5IHBlb3Bs ZSB3aG8gam9pbiBjYW4NCnNlZSB3aGF0J3MgdGhlcmUuIFdlIGNhbiB1c2UgdGhlIHNpdGUgdG8g c2hhcmUgZmlsZXMsIHBpY3R1cmVzLCBhbmQNCmxpbmtzLCBjb29yZGluYXRlIGV2ZW50cywgYW5k IGtlZXAgZXZlcnlvbmUgdXAtdG8tZGF0ZSBvbiBpbXBvcnRhbnQNCmdyb3VwIGFubm91bmNlbWVu dHMuIFlvdSBkb24ndCBuZWVkIGFueXRoaW5nIHNwZWNpYWwgdG8gY29ubmVjdCB0bw0KdGhlIHNp dGU7IGp1c3QgYSB3ZWIgYnJvd3NlciBhbmQgYW4gSW50ZXJuZXQgY29ubmVjdGlvbi4gQnV0IHlv dQ0KZG8gbmVlZCB0byBzaWduIHVwIHRvIGJlY29tZSBhIG1lbWJlci4gDQoNCkhlcmUncyBob3cg dG8gam9pbi4uLiANCg0KMS4gR28gdG8gaHR0cDovL2JhcmZsLndlYmV4b25lLmNvbS9yZWdpc3Rl cl9tZW1iZXIuYXNwDQoyLiBGaWxsIG91dCB0aGUgaW5mb3JtYXRpb24gb24gdGhlIG5ldyBtZW1i ZXIgZm9ybSB1c2luZyB0aGUgUmVnaXN0cmF0aW9uDQpDb2RlOiBiYXJmWHgNCg0KMy4gVGhhdCdz IGl0IQ0KDQpKdXN0IG1ha2Ugc3VyZSB0aGF0IHdoZW4geW91IGVudGVyIHRoZSBSZWdpc3RyYXRp b24gQ29kZSwgeW91IHR5cGUNCml0IGp1c3QgbGlrZSBpdCdzIHNob3duIGFib3ZlIGJlY2F1c2Ug aXQgaXMgY2FzZS1zZW5zaXRpdmUuIEFsc28sDQpiZSBzdXJlIHRvIGtlZXAgdGhlIFJlZ2lzdHJh dGlvbiBDb2RlIHByaXZhdGUgYmVjYXVzZSBhbnlvbmUgd2hvDQprbm93cyBpdCBjYW4gam9pbiB0 aGUgd2ViIG9mZmljZS4NCg0KRW5qb3kgeW91ciB3ZWIgb2ZmaWNlIQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpodHRwOi8vV2ViZXhvbmUuY29tIA0KR2V0IGV2ZXJ5b25lIG9u IHRoZSBzYW1lIHBhZ2UuIFNNDQo= From owner-freebsd-drivers@FreeBSD.ORG Wed Sep 19 12:08:42 2012 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E7FB106564A for ; Wed, 19 Sep 2012 12:08:42 +0000 (UTC) (envelope-from jacks.1785@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 495308FC0A for ; Wed, 19 Sep 2012 12:08:42 +0000 (UTC) Received: by iea17 with SMTP id 17so1803481iea.13 for ; Wed, 19 Sep 2012 05:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IYWg9boG0/zsmo1iPZG0ajeib6p2ED8Yz35hgsjP1Mg=; b=m3C3W4cx1VCftufYLBVaxg5QuGL0Vxkm49nt2gwsYZjZ/5Xi84ACrH8nxbGHaMrHRR 6bjbl+O6iatWn5h/ATWWI6tp/8lLIk6/HuZXKU7cky36JGh9REZUvJ7Eoz+loCnAUArN oFDn+QtB4vGym6l7dEAtsn9NXXZMDKKG6jg0/SNqvtnB2+Z9OLAaAWGjY7sGTfold77/ TtI8GoFc+QdyiAhorpzusykXhQADnPDPREIdwyjmzPVF61ad1KSeARll7ThIXki7ncPw IHGxliA3Wj++N6YCrEHGOOWh0hieJ2f7caO/+FO5BWzM9xdaEKWCb3Peys3P/pLmjL78 dvXg== MIME-Version: 1.0 Received: by 10.50.94.166 with SMTP id dd6mr2755693igb.55.1348056521809; Wed, 19 Sep 2012 05:08:41 -0700 (PDT) Received: by 10.64.44.105 with HTTP; Wed, 19 Sep 2012 05:08:41 -0700 (PDT) Date: Wed, 19 Sep 2012 17:38:41 +0530 Message-ID: From: jack sparrow To: freebsd-drivers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Exclusive access of SCSI/ATA devices from user space X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 12:08:42 -0000 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. Thanks. From owner-freebsd-drivers@FreeBSD.ORG Wed Sep 19 12:25:11 2012 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B51EF1065678; Wed, 19 Sep 2012 12:25:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 889458FC15; Wed, 19 Sep 2012 12:25:11 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 07A6FB97D; Wed, 19 Sep 2012 08:25:11 -0400 (EDT) From: John Baldwin To: freebsd-drivers@freebsd.org Date: Wed, 19 Sep 2012 08:25:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209190825.07384.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 19 Sep 2012 08:25:11 -0400 (EDT) Cc: jack sparrow , Alexander Motin Subject: Re: Exclusive access of SCSI/ATA devices from user space X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 12:25:11 -0000 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 From owner-freebsd-drivers@FreeBSD.ORG Wed Sep 19 13:45:07 2012 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5A01106566C; Wed, 19 Sep 2012 13:45:07 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED1CE8FC15; Wed, 19 Sep 2012 13:45:06 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so1155743lbb.13 for ; Wed, 19 Sep 2012 06:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vlH0pcPABSY2t9FFm+FKccInxMTFpRr2V03srdzFa/Y=; b=laRSDpxVc4uJZBLuxqUO3i2ZPlYDPVBCu5eH/cgJRilbM2xeHHHCEM3mAT+RFb3xkH xApkOjAJiJX3xC6ET81a0d9ec19PC17+fdukPPb/FFQ8mErT5KyroXHlYZZHPep8CViH 83UV9p2jwJTENj1b1ksZDq2IclEYGIG9EsA0fKjzrgGlER4nco263BL9vI3n0bJf0rtb bg5326LDAjkO7HECthuiFGDnZvs4Ah6RrxKJF9H8AvreLU1cpRgaTTW1ZTmrORiYT75J lCx1dcXFlnMmxD5haVfKGnrLNz72fpQ8Bf512V8emsvQVPhHGtSO8AXWKrxRhyuILWLJ yrOQ== Received: by 10.152.105.210 with SMTP id go18mr2813179lab.13.1348062299634; Wed, 19 Sep 2012 06:44:59 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id r1sm815016lbk.12.2012.09.19.06.44.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 06:44:58 -0700 (PDT) Sender: Alexander Motin Message-ID: <5059CC56.8040705@FreeBSD.org> Date: Wed, 19 Sep 2012 16:44:54 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: jack sparrow References: <201209190825.07384.jhb@freebsd.org> In-Reply-To: <201209190825.07384.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-drivers@freebsd.org Subject: Re: Exclusive access of SCSI/ATA devices from user space X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 13:45:07 -0000 On 19.09.2012 15:25, John Baldwin wrote: > 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. Jack. You've started your mail speaking about SCSI/ATA layer access, but finished closer to block device layer. Each device can be accessed both ways, depending on your needs. SCSI/ATA access you may get through the CAM pass driver. It allows you to run any SCSI or ATA commands, it does not modify them and does not reorder them during normal operation. But CAM does not restrict simultaneous access to the devices, so the same device can be accessed through both pass and da/ada drivers (or any other if they happen) at the same time. Usually it is not a problem because pass interface is used only by short list of tools, like ones for CD/DVD recording. Block access you may get through da/ada CAM drivers and respectfully through GEOM. GEOM does controls concurrent device access. If you open some device from user-level for writing, nothing else will be able to access it at the same time on a block layer (raw access through the pass driver is still possible). But before device can be opened, GEOM will do its usual job, tasting device for some metadata, partitions, file systems, etc. I don't know whether it is a problem, but the only way to prevent that is hack CAM transport or da/ada drivers to not attach to specific devices at all, leaving only pass interface. Also, as John told, there is a request sorter on a top side of ada and da drivers. So if several request sent simultaneously, they may be reordered. There is special BIO request flag BIO_ORDERED to force original request order, but I don't know way to send it from user-level. If you need absolute guarantee of order, you should wait for request completion. Neither CAM nor GEOM are caching requests, so that will help with ordering, but limit performance. CAM provides control over ATA PIO/DMA modes via camcontrol tool or respective calls via the pass interface. It works for all supported ATA/SATA controllers. For SAS controllers it can be problematic, as these controllers implement some translation and may not provide such interfaces. -- Alexander Motin From owner-freebsd-drivers@FreeBSD.ORG Wed Sep 19 15:26:47 2012 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BDB5106566C for ; Wed, 19 Sep 2012 15:26:47 +0000 (UTC) (envelope-from jacks.1785@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 206998FC0C for ; Wed, 19 Sep 2012 15:26:47 +0000 (UTC) Received: by iea17 with SMTP id 17so2281392iea.13 for ; Wed, 19 Sep 2012 08:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=i16vvXF28hSTiWO0D15SII5cbQW8+iJxGG7DqUMsOwI=; b=AEiQQy0vEGT/pRr0V7NdjFRCyGVg3ijUcrbld7YfClxJEOUDh2n2Jxflo715IyZ9hE xFJhjRWM9vFHrlTLYQVfIdd2uQlX7voNCK950x5wsQGr4tLGmC+c8IlIZaK5JPdobmOA TYwO29kUtqPRG/Q73M4QtV3LpLCNhHvguj21AkAedUMDbmbyF6+8/D14AS87C9G1ri9h iCl4FNttSvjv2OG2yZkINKh4vJKENAQLCJjBFN23kaxZlbolf+05zJFIdZQOYLUgZ+OF wCsXF9I5b9K0yYapahiXLLn1JZCnbbyyU8cozDPyfCr8TL6N4M2mojcTXse44eXdCrN0 we9w== MIME-Version: 1.0 Received: by 10.50.181.168 with SMTP id dx8mr3161533igc.8.1348068406510; Wed, 19 Sep 2012 08:26:46 -0700 (PDT) Received: by 10.64.44.105 with HTTP; Wed, 19 Sep 2012 08:26:46 -0700 (PDT) In-Reply-To: References: <201209190825.07384.jhb@freebsd.org> <5059CC56.8040705@FreeBSD.org> Date: Wed, 19 Sep 2012 20:56:46 +0530 Message-ID: From: Jack To: freebsd-drivers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Exclusive access of SCSI/ATA devices from user space X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 15:26:47 -0000 On Wed, Sep 19, 2012 at 8:53 PM, Jack wrote: > On Wed, Sep 19, 2012 at 7:14 PM, Alexander Motin wrote: >> On 19.09.2012 15:25, John Baldwin wrote: >>> >>> 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. >> >> >> Jack. You've started your mail speaking about SCSI/ATA layer access, but >> finished closer to block device layer. Each device can be accessed both >> ways, depending on your needs. >> >> SCSI/ATA access you may get through the CAM pass driver. It allows you to >> run any SCSI or ATA commands, it does not modify them and does not reorder >> them during normal operation. But CAM does not restrict simultaneous access >> to the devices, so the same device can be accessed through both pass and >> da/ada drivers (or any other if they happen) at the same time. Usually it is >> not a problem because pass interface is used only by short list of tools, >> like ones for CD/DVD recording. >> >> Block access you may get through da/ada CAM drivers and respectfully through >> GEOM. GEOM does controls concurrent device access. If you open some device >> from user-level for writing, nothing else will be able to access it at the >> same time on a block layer (raw access through the pass driver is still >> possible). But before device can be opened, GEOM will do its usual job, >> tasting device for some metadata, partitions, file systems, etc. I don't >> know whether it is a problem, but the only way to prevent that is hack CAM >> transport or da/ada drivers to not attach to specific devices at all, >> leaving only pass interface. Also, as John told, there is a request sorter >> on a top side of ada and da drivers. So if several request sent >> simultaneously, they may be reordered. There is special BIO request flag >> BIO_ORDERED to force original request order, but I don't know way to send it >> from user-level. If you need absolute guarantee of order, you should wait >> for request completion. Neither CAM nor GEOM are caching requests, so that >> will help with ordering, but limit performance. >> >> CAM provides control over ATA PIO/DMA modes via camcontrol tool or >> respective calls via the pass interface. It works for all supported ATA/SATA >> controllers. For SAS controllers it can be problematic, as these controllers >> implement some translation and may not provide such interfaces. >> >> -- >> Alexander Motin > Thank you both, for your responses, I'll need to grasp the approaches you discussed. I'll post the update. Thanks. From owner-freebsd-drivers@FreeBSD.ORG Thu Sep 20 06:31:50 2012 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DD29106566C for ; Thu, 20 Sep 2012 06:31:50 +0000 (UTC) (envelope-from jacks.1785@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id D73BE8FC17 for ; Thu, 20 Sep 2012 06:31:49 +0000 (UTC) Received: by iea17 with SMTP id 17so3779891iea.13 for ; Wed, 19 Sep 2012 23:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=s7dF31kKuyrZN0WkD6uEnqwL9dei9LHtOEFmbzkIgQg=; b=J4HAdVjBTcG+w6RzdT+TrmZ6xJQVxMQJexQ0xYjKQb06WH0uU1MycgnvcFH/OxHtjo j7ZMBwBYDIZc7NASe9Y6Qa13RQyuEDQ1i/zXBC9VBvSjtEbT/M2+Cp8vd5O847Jc9v50 899AfUBO7rXq6TkBtQphPaz6bu7hDzQCwTnrFCUD4fgyrXJgZFu7Xw0uumNVY+RMGbQ/ zzIbJznD9ZXey8XMGf6tnNkTTMGGiowGmH77R+wXdCa5MCBZWToMBTZpBBFWcHncsCzP qUtDjVQUT+HhIV0uITCOHGSJxMd6PphXREfSFYHXgcr0/Uyaol5XKqvVPZJ4KmITjOdC p3JA== MIME-Version: 1.0 Received: by 10.50.180.227 with SMTP id dr3mr839106igc.1.1348122709096; Wed, 19 Sep 2012 23:31:49 -0700 (PDT) Received: by 10.64.44.105 with HTTP; Wed, 19 Sep 2012 23:31:49 -0700 (PDT) In-Reply-To: References: <201209190825.07384.jhb@freebsd.org> <5059CC56.8040705@FreeBSD.org> Date: Thu, 20 Sep 2012 12:01:49 +0530 Message-ID: From: Jack To: freebsd-drivers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Exclusive access of SCSI/ATA devices from user space X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 06:31:50 -0000 On Wed, Sep 19, 2012 at 8:53 PM, Jack wrote: > On Wed, Sep 19, 2012 at 7:14 PM, Alexander Motin wrote: >> On 19.09.2012 15:25, John Baldwin wrote: >>> >>> 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. >> >> >> Jack. You've started your mail speaking about SCSI/ATA layer access, but >> finished closer to block device layer. Each device can be accessed both >> ways, depending on your needs. >> >> SCSI/ATA access you may get through the CAM pass driver. It allows you to >> run any SCSI or ATA commands, it does not modify them and does not reorder >> them during normal operation. But CAM does not restrict simultaneous access >> to the devices, so the same device can be accessed through both pass and >> da/ada drivers (or any other if they happen) at the same time. Usually it is >> not a problem because pass interface is used only by short list of tools, >> like ones for CD/DVD recording. >> >> Block access you may get through da/ada CAM drivers and respectfully through >> GEOM. GEOM does controls concurrent device access. If you open some device >> from user-level for writing, nothing else will be able to access it at the >> same time on a block layer (raw access through the pass driver is still >> possible). But before device can be opened, GEOM will do its usual job, >> tasting device for some metadata, partitions, file systems, etc. I don't >> know whether it is a problem, but the only way to prevent that is hack CAM >> transport or da/ada drivers to not attach to specific devices at all, >> leaving only pass interface. Also, as John told, there is a request sorter >> on a top side of ada and da drivers. So if several request sent >> simultaneously, they may be reordered. There is special BIO request flag >> BIO_ORDERED to force original request order, but I don't know way to send it >> from user-level. If you need absolute guarantee of order, you should wait >> for request completion. Neither CAM nor GEOM are caching requests, so that >> will help with ordering, but limit performance. >> >> CAM provides control over ATA PIO/DMA modes via camcontrol tool or >> respective calls via the pass interface. It works for all supported ATA/SATA >> controllers. For SAS controllers it can be problematic, as these controllers >> implement some translation and may not provide such interfaces. >> >> -- >> Alexander Motin > > Thank you both, for your responses, I'll need to grasp the approaches > you discussed. I'll post the update. > Thanks. So, basically to follow these requirements in utility: 1. No other userland process is allowed to access the selected device while utility is accessing the device. 2. No disk I/O sorting on selected device, must be done. 3. Utility can specify whether to transfer data via PIO or DMA(in case of ata devices). 4. issue IDLE or Standby, reset device comand, and similar commands to drive. 5. I also need to disable(if enabled) SATA NCQ, and Command tag queing( in SCSI drives), on the selected device. 6. No kernel level buffering, for selected device's I/O request data transfer. it seems that I need to modify da/ada/sa drivers, so that they do not get attach themselves to the selected device. (The above requirements/contraints only apply to the device that is selected, they do not apply on other scsi/ata devices attached to the system. The other device will be accessed by the utility in normal manner.) After going through the approaches mentioned, following issues arose to my understanding. 1. It seems that raw device(device = tape or hard drive, here) layer is different from CAM passthrough driver. ie raw device access do go though GEOM layer, while CAM passthrough accesses go directly to da/sda/sa drivers of CAM sub-system, bypassing GEOM layer completely. Am I right? If it is true then I dont' need to modify GEOM layer - just modify the default da/ada/sa driver and access the device through cam pass driver. 2. Will only modifying the default da/ada/sa drivers(so that they do not get attach themselves to selected device) will do the work? I mean do I have to also modify default GEOM layer, or add a new customized GEOM module, or, do I need to modify layers above or below the da/sda/sa drivers in CAM subsystem? Do I need to modify on each controller(host bus adapter) driver? Since AFAIK, decisions like I/O request sorting and PIO/DMA in case of ata devices, are done at the CAM peripheral layer, or CAM transport layer. Please correct me if I'm wrong. Actually I'm asking this so that rather than making modifications at many layers/modules, it would be nice to modify a single layer or module, so that we will not compromise the kernel stability, and consistency. 3. Will modifying default da/sda/sa drivers(so that they do not get attach themselves to selected device) affect other device's access, e.g. sorting of I/O requests, etc.? Since there is a request sorter on a top side of default ada and da drivers, I need to disable sorting of I/O requests on selected device, right from the beginning, ie as soon as device is selected. Is there a way to disable I/O sorting only for a particular device, or will I need to modify default da/ada/sa drivers such that they don't do I/O request sorting at all. In this case, of course I/O requests for other devices, will also not get sorted, but that is ok, if it is the only solution. In short, the purpose of modifying default da/ada/sa drivers is : a) so that they do not attach themselves to the seleted device, or if already attached then they must detach themselves from the selected device, as soon as the device is selected. b) so that no sorting of I/O request for selected device, is done. 4. Two more things I would like to stress, are that the data transfer from selected device via utility, can be many gigabytes, and that other devices will be accessed by the utility in normal manner, like via read(), write(), ioctl(), calls. Will modifying default da/ada/sa, can have any negative effect on accesses made for other devices in normal way? I tried my best to clarify the issues, but if more clarification is needed about any of the above issue, please let me know. Thanks From owner-freebsd-drivers@FreeBSD.ORG Thu Sep 20 12:18:35 2012 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CA391065672 for ; Thu, 20 Sep 2012 12:18:35 +0000 (UTC) (envelope-from jacks.1785@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3EFD08FC16 for ; Thu, 20 Sep 2012 12:18:35 +0000 (UTC) Received: by ieak10 with SMTP id k10so541283iea.13 for ; Thu, 20 Sep 2012 05:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=a2moJXR/zTsyG8H/GZs2heIvHRu8hOfbdqN13T+BXB8=; b=ZqNyqLzOsOdLqvZvQ5v3ZDWq6jmEQP7VBouUfnQt7qkD8fshxwQDYXA+nJUb6gFJ/y 7Qxt1VRX+8+1RXjnQhmAWCDwJ3mn09qtMPRuBgqUno3fJZbMDyKAVpM1GbVGERidzTzM kCDOJWLF4mN0jQ83oMOVpEAis+Zun0TPdMWLEnT/o0UUJqbcHXZ6+FhLIpM2RJPpN26m ztUUECznnz145Z/vKA01k3Dbh4h5HEyuaUKda0erGFYMU7U38co/xLN+TFguvaBEHZBH 0sfH/oA8p8gUG7AoYzV+JLPfTZlB2MefwQgtWEJd7xWd8dN950nzEd3AeT7P4gmUmKHC 7VfA== MIME-Version: 1.0 Received: by 10.50.212.66 with SMTP id ni2mr2287906igc.1.1348143514487; Thu, 20 Sep 2012 05:18:34 -0700 (PDT) Received: by 10.64.44.105 with HTTP; Thu, 20 Sep 2012 05:18:34 -0700 (PDT) In-Reply-To: References: <201209190825.07384.jhb@freebsd.org> <5059CC56.8040705@FreeBSD.org> Date: Thu, 20 Sep 2012 17:48:34 +0530 Message-ID: From: Jack To: freebsd-drivers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Exclusive access of SCSI/ATA devices from user space X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 12:18:35 -0000 On 9/20/12, Jack wrote: > On Wed, Sep 19, 2012 at 8:53 PM, Jack wrote: >> On Wed, Sep 19, 2012 at 7:14 PM, Alexander Motin wrote: >>> On 19.09.2012 15:25, John Baldwin wrote: >>>> >>>> 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. >>> >>> >>> Jack. You've started your mail speaking about SCSI/ATA layer access, but >>> finished closer to block device layer. Each device can be accessed both >>> ways, depending on your needs. >>> >>> SCSI/ATA access you may get through the CAM pass driver. It allows you >>> to >>> run any SCSI or ATA commands, it does not modify them and does not >>> reorder >>> them during normal operation. But CAM does not restrict simultaneous >>> access >>> to the devices, so the same device can be accessed through both pass and >>> da/ada drivers (or any other if they happen) at the same time. Usually it >>> is >>> not a problem because pass interface is used only by short list of >>> tools, >>> like ones for CD/DVD recording. >>> >>> Block access you may get through da/ada CAM drivers and respectfully >>> through >>> GEOM. GEOM does controls concurrent device access. If you open some >>> device >>> from user-level for writing, nothing else will be able to access it at >>> the >>> same time on a block layer (raw access through the pass driver is still >>> possible). But before device can be opened, GEOM will do its usual job, >>> tasting device for some metadata, partitions, file systems, etc. I don't >>> know whether it is a problem, but the only way to prevent that is hack >>> CAM >>> transport or da/ada drivers to not attach to specific devices at all, >>> leaving only pass interface. Also, as John told, there is a request >>> sorter >>> on a top side of ada and da drivers. So if several request sent >>> simultaneously, they may be reordered. There is special BIO request flag >>> BIO_ORDERED to force original request order, but I don't know way to send >>> it >>> from user-level. If you need absolute guarantee of order, you should >>> wait >>> for request completion. Neither CAM nor GEOM are caching requests, so >>> that >>> will help with ordering, but limit performance. >>> >>> CAM provides control over ATA PIO/DMA modes via camcontrol tool or >>> respective calls via the pass interface. It works for all supported >>> ATA/SATA >>> controllers. For SAS controllers it can be problematic, as these >>> controllers >>> implement some translation and may not provide such interfaces. >>> >>> -- >>> Alexander Motin >> >> Thank you both, for your responses, I'll need to grasp the approaches >> you discussed. I'll post the update. >> Thanks. > > So, basically to follow these requirements in utility: > > 1. No other userland process is allowed to access the selected device > while utility is accessing the device. > 2. No disk I/O sorting on selected device, must be done. > 3. Utility can specify whether to transfer data via PIO or DMA(in case > of ata devices). > 4. issue IDLE or Standby, reset device comand, and similar commands to > drive. > 5. I also need to disable(if enabled) SATA NCQ, and Command tag > queing( in SCSI drives), on the selected device. > 6. No kernel level buffering, for selected device's I/O request data > transfer. > > it seems that I need to modify da/ada/sa drivers, so that they do not > get attach themselves to the selected device. > > (The above requirements/contraints only apply to the device that is > selected, they do not apply on other scsi/ata devices > attached to the system. The other device will be accessed by the > utility in normal manner.) > > After going through the approaches mentioned, following issues arose > to my understanding. > > 1. It seems that raw device(device = tape or hard drive, here) layer > is different from CAM passthrough driver. ie raw device > access do go though GEOM layer, while CAM passthrough accesses go > directly to da/sda/sa drivers of CAM sub-system, bypassing GEOM layer > completely. Am I right? > If it is true then I dont' need to modify GEOM layer - just modify > the default da/ada/sa driver and access the device > through cam pass driver. > > > 2. Will only modifying the default da/ada/sa drivers(so that they do > not get attach themselves to selected device) will do > the work? > I mean do I have to also modify default GEOM layer, or add a new > customized GEOM module, or, do I need to modify layers above or below > the da/sda/sa drivers in CAM subsystem? > Do I need to modify on each controller(host bus adapter) driver? > Since AFAIK, decisions like I/O request sorting and PIO/DMA in case of > ata devices, are done at the CAM peripheral layer, or CAM transport > layer. Please correct me if I'm wrong. > Actually I'm asking this so that rather than making modifications at > many layers/modules, it would be nice to modify a > single layer or module, so that we will not compromise the kernel > stability, and consistency. > > > > 3. Will modifying default da/sda/sa drivers(so that they do not get > attach themselves to selected device) affect other > device's access, e.g. sorting of I/O requests, etc.? > > Since there is a request sorter on a top side of default ada and da > drivers, I need to disable sorting of I/O requests on > selected device, right from the beginning, ie as soon as device is > selected. > Is there a way to disable I/O sorting only for a particular device, or > will I need to modify default da/ada/sa drivers such > that they don't do I/O request sorting at all. In this case, of course > I/O requests for other devices, will also not get > sorted, but that is ok, if it is the only solution. > > In short, the purpose of modifying default da/ada/sa drivers is : > a) so that they do not attach themselves to the seleted device, or if > already attached then they must detach themselves from the selected > device, as soon as the device is selected. > b) so that no sorting of I/O request for selected device, is done. > > 4. Two more things I would like to stress, are that the data transfer > from selected device via utility, can be many > gigabytes, and that other devices will be accessed by the utility in > normal manner, like via read(), write(), ioctl(), calls. > Will modifying default da/ada/sa, can have any negative effect on > accesses made for other devices in normal way? > > > > I tried my best to clarify the issues, but if more clarification is > needed about any of the above issue, please let me know. > > Thanks > hello again, Okay, this time I'm more clear. Below is the ascii artwork to show the flow of control that will happen when a I/O request is issued to the selected device via CAM pass through driver. All the I/O layers involved, are shown. Assume that we modified da/ada/sa drivers so they will not attach to this selected device. Nothing else is modified. _________________________________ | | | utility code | |________________________________| | | | read / write / ioctl system calls on | | pass device created | |________________________________| | | | CAM passthrough driver | | Send CAM control Blocks to XPT | |_________________________________| | | | CAM Transport Layer(XPT) | | communication to upper layers is via | | CAM Control Blocks (CCB). | |_________________________________| | | | SCSI Interface Module(SIM), or | | HBA driver module | | Parallel SCSI(SPI), Fibre channel(FC), | | USB Mass Storage(UMASS), | | FireWire(IEEE 1394), ATAPI. | | SAS and SATA/ATA | |_________________________________| Please feel free to correct me if I am wrong in the control flow in above diagram. Is there really no sorting of I/O requests inside cam passthrough driver, or cam transport layer? Say if I send one i/o request to selected device via cam passthrough driver and then send other one, before previous one is completed. Do I need to modify cam transport layer also, to switch ata device from PIO to DMA and vice versa for data transfer and to disable SATA NCQ, and Command tag queing ; or CAM passthrough driver will be able to do that. It seems that all this should be suffice for following the below requirements: 1. No other userland process is allowed to access the selected device while utility is accessing the device. 2. No disk I/O sorting on selected device, must be done. 3. Utility can specify whether to transfer data via PIO or DMA(in case of ata devices). 4. issue IDLE or Standby, reset device comand, and similar commands to drive. 5. I also need to disable(if enabled) SATA NCQ, and Command tag queing( in SCSI drives), on the selected device. 6. No kernel level buffering, for selected device's I/O request data transfer. Thanks From owner-freebsd-drivers@FreeBSD.ORG Thu Sep 20 19:23:14 2012 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32E76106566B; Thu, 20 Sep 2012 19:23:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 718BF8FC0C; Thu, 20 Sep 2012 19:23:12 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so3580153lbb.13 for ; Thu, 20 Sep 2012 12:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3/a92f5gNxBkWPfeC/TC+Ppb6hUBaX2iJupEPOt1EOM=; b=CgjbmL1RFZk9fb7dTUGgV5yTAESec3ICjBwDl0cZ5tY+EXiD3MntksAlrpUI1u+deR zGQEclSnw06UY8HJ0uEmvmFRReERlnkllVim/VBPsEwydD8MLeef8J6LKk4hKOUOu8zM lHPHv8rUpN3c6ErAt2yw2nfpgE875Meepa13MKsh6AnKFiEuMb5gwhUtXjXnER4mR1p8 56b2/cWBa9ZkOe7SHTnCS6sApLaKnpCTCgYdjDmt+t5XBuwVmIlx/csu++orVHx9u2eE rnGcEdwQCufbuTQAmuSNYOhpOmWBJpk3iAEworKEHdjJKBFSIMme75y/sR0SvKcH0p/9 KsOQ== Received: by 10.152.132.202 with SMTP id ow10mr2287761lab.51.1348168991090; Thu, 20 Sep 2012 12:23:11 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id ba4sm1765886lbb.14.2012.09.20.12.23.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Sep 2012 12:23:09 -0700 (PDT) Sender: Alexander Motin Message-ID: <505B6D1B.7070506@FreeBSD.org> Date: Thu, 20 Sep 2012 22:23:07 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: jack sparrow References: <201209190825.07384.jhb@freebsd.org> <5059CC56.8040705@FreeBSD.org> In-Reply-To: <5059CC56.8040705@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-drivers@freebsd.org Subject: Re: Exclusive access of SCSI/ATA devices from user space X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 19:23:14 -0000 > Is there really no sorting of I/O requests inside cam passthrough > driver, or cam transport layer? Say if I send one i/o request to > selected device via cam passthrough driver and then send other one, > before previous one is completed. There is no sorting in pass driver, as it passes all requests to CAM immediately. CAM transport also does not intentionally sort requests during normal operation. In some rare error recovery cases it may be difficult to manage original request order during requests requeueing or retrying. CAM tries to do it right, but I am not sure it can be guarantied. > Do I need to modify cam transport layer also, to switch ata device > from PIO to DMA and vice versa for data transfer and to disable SATA > NCQ, and Command tag queing ; or CAM passthrough driver will be able > to do that. No, you don't need to modify. CAM provides APIs to control mode setting and command queuing via methods of the same PASS interface. If you are using pass interface, it is actually your duty to use proper command set (PIO/DMA/FPDMA) with the device, respecting current operation mode set by CAM. If CAM negotiated DMA with NCQ, you are free to use any of these kinds of commands in a mix you like. -- Alexander Motin From owner-freebsd-drivers@FreeBSD.ORG Fri Sep 21 04:15:08 2012 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FCD6106566C; Fri, 21 Sep 2012 04:15:08 +0000 (UTC) (envelope-from jacks.1785@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id BD7B88FC0C; Fri, 21 Sep 2012 04:15:07 +0000 (UTC) Received: by ieak10 with SMTP id k10so2351855iea.13 for ; Thu, 20 Sep 2012 21:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kcdO99PbpNehf6zhjfR9lndXZSQTsjOrTaOHQj8qsbk=; b=G0zSa5O4OM8EhcRdJtqgqopulrfWAO+rkF+2jnSjEKcbzmL28uDHq0dN2hqQnuBDwi TemZJ4VV7sPMM9g2k/kPafAHH1CCHRuiO0qH6tUo0mMJjMTGPeizq/6p3O2qomP3bhFu pyvufmdbMUUd4C37quYetKBF21J8Bv1yJJ3Ms5/d+JQc7dYsnpcaBU03OG2SsYhr8Cih kffuAPLsRAfVzkq/T8mKxuS/lg8x+1GdG0k9/kXUY5PSLxFY3f0wN6Dgfsixl24wYkA2 Kqc83BUDjVFO18XkzDXAaNT/zHURCr5PVbnWpNFWmNBNW6EYtSIL+xBXa76xpJXQh6dv 5yDg== MIME-Version: 1.0 Received: by 10.50.186.196 with SMTP id fm4mr599872igc.8.1348200906768; Thu, 20 Sep 2012 21:15:06 -0700 (PDT) Received: by 10.64.44.105 with HTTP; Thu, 20 Sep 2012 21:15:06 -0700 (PDT) In-Reply-To: <505B6D1B.7070506@FreeBSD.org> References: <201209190825.07384.jhb@freebsd.org> <5059CC56.8040705@FreeBSD.org> <505B6D1B.7070506@FreeBSD.org> Date: Fri, 21 Sep 2012 09:45:06 +0530 Message-ID: From: Jack To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-drivers@freebsd.org Subject: Re: Exclusive access of SCSI/ATA devices from user space X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 04:15:08 -0000 On 9/21/12, Alexander Motin wrote: > > Is there really no sorting of I/O requests inside cam passthrough > > driver, or cam transport layer? Say if I send one i/o request to > > selected device via cam passthrough driver and then send other one, > > before previous one is completed. > > There is no sorting in pass driver, as it passes all requests to CAM > immediately. CAM transport also does not intentionally sort requests > during normal operation. In some rare error recovery cases it may be > difficult to manage original request order during requests requeueing or > retrying. CAM tries to do it right, but I am not sure it can be guarantied. > > > Do I need to modify cam transport layer also, to switch ata device > > from PIO to DMA and vice versa for data transfer and to disable SATA > > NCQ, and Command tag queing ; or CAM passthrough driver will be able > > to do that. > > No, you don't need to modify. CAM provides APIs to control mode setting > and command queuing via methods of the same PASS interface. If you are > using pass interface, it is actually your duty to use proper command set > (PIO/DMA/FPDMA) with the device, respecting current operation mode set > by CAM. If CAM negotiated DMA with NCQ, you are free to use any of these > kinds of commands in a mix you like. > > -- > Alexander Motin > Thanks Alexander. So, I only need to modify da/ada/sa drivers such that they do not attach themselves to the selected device. Then I will access the device via CAM pass driver. Is it possible that 2 different processes can access the same device via cam pass through driver? Actually there are 2 perspectives here, I'm talking about: ( Assume we have modified da/ada/sa drivers such that they do not attach themselves to the selected device, and utility is loaded in main memory. ) a) While one processes is accessing the selected device via cam pass driver, is it possible for another process to access this same selected device via cam pass driver(it can't access through da/ada/sa drivers as they are not attached to the selected device rightnow). I'm trying to deactivate/disable simultaneous access to the selected device. b) Assume that none of the process is currently accessing the selected device. Is it possible that except my utility, none of the other userland processes be able to access the selected device via cam pass driver(again, it can't access through da/ada/sa drivers), even if my utility is not accessing the device at this time. I mean, is there some kind of automatic or forced locking so that only utility process can access the selected device via CAM passthrough driver. -- Jack From owner-freebsd-drivers@FreeBSD.ORG Sat Sep 22 04:59:55 2012 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C6771065675; Sat, 22 Sep 2012 04:59:55 +0000 (UTC) (envelope-from jacks.1785@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3538A8FC1C; Sat, 22 Sep 2012 04:59:54 +0000 (UTC) Received: by ieak10 with SMTP id k10so5713448iea.13 for ; Fri, 21 Sep 2012 21:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ChPh2UYrmjAmLRz8Q/22WJ4vy7LHJ0U9cDOZLanCL9w=; b=kfMsLYEyHsQI2T7yL6OkYBsCOt+GZxykDCeXaw4IDZjA7DC6fx/kYGRDQUbnE4THJk 02d0Tc7PdZo16lRri0m8+dJK6w/iyzwtbdSPbgw5LbSJMSnPpI7EtO3HDPVv20w4dCQ8 TLhUCGGctziqRDEn/4YEUKcOkc3fTtgrGkP7U0u75n6LGE4R2ieEk6zILJTmZItO3c1t 8Cn0ujYxmiuab2wFHQLdb8m/8lT4RwHf9Faqer5+g3RJKPiNivNgKJA1oRSIQ/c9ipt5 TRGE+do03TZRz9MmSZMhZ3J8sA913ZdOVvME4JmVin+FeHQMMsIMQpRWAt/K3iRjxAop oGDw== MIME-Version: 1.0 Received: by 10.43.16.67 with SMTP id px3mr5456092icb.17.1348289993527; Fri, 21 Sep 2012 21:59:53 -0700 (PDT) Received: by 10.64.44.105 with HTTP; Fri, 21 Sep 2012 21:59:53 -0700 (PDT) In-Reply-To: References: <201209190825.07384.jhb@freebsd.org> <5059CC56.8040705@FreeBSD.org> <505B6D1B.7070506@FreeBSD.org> Date: Sat, 22 Sep 2012 10:29:53 +0530 Message-ID: From: Jack To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-drivers Subject: Re: Exclusive access of SCSI/ATA devices from user space X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 04:59:55 -0000 On 9/21/12, Jack wrote: > > Thanks Alexander. So, I only need to modify da/ada/sa drivers such > that they do not attach themselves to the selected device. Then I will > access the device via CAM pass driver. > > Is it possible that 2 different processes can access the same device > via cam pass through driver? > > Actually there are 2 perspectives here, I'm talking about: > ( Assume we have modified da/ada/sa drivers such that they do not > attach themselves to the selected device, and utility is loaded in > main memory. ) > > a) While one processes is accessing the selected device via cam pass > driver, is it possible for another process to access this same > selected device via cam pass driver(it can't access through da/ada/sa > drivers as they are not attached to the selected device rightnow). I'm > trying to deactivate/disable simultaneous access to the selected > device. > > b) Assume that none of the process is currently accessing the selected > device. Is it possible that except my utility, none of the other > userland processes be able to access the selected device via cam pass > driver(again, it can't access through da/ada/sa drivers), even if my > utility is not accessing the device at this time. I mean, is there > some kind of automatic or forced locking so that only utility process > can access the selected device via CAM passthrough driver. > > -- > Jack > It seems that I misunderstood your first post. I'm quoting it for reference. > > ... CAM does not restrict simultaneous access to the devices, so the same device can be > accessed through both pass and da/ada drivers (or any other if they happen) at the same > time. Usually it is not a problem because pass interface is used only by short list of tools, > like ones for CD/DVD recording. > So, two or more processes can access the same device simultaneously, via cam pass driver, or one via cam pass driver and other one via block access, but two or more processes simultaneously can't access same device via block interface - GEOM does controls concurrent device access. Now is it possible that we can restrict access to a pass device solely to a particular process(ie my utility), so that no other process(neither simultaneously, nor at time when no other process is accessing the selected device), would ever be able to access the selected device via cam pass driver - e.g. some sort of lock on pass device or something like that. Assuming that da/ada/sa drivers are not attached to the selected device, if it is possible to put the above mentioned restriction on pass device, then the only process, that can access the selected device will be the utility's process, and none else. -- Jack