Date: Thu, 29 Jul 2004 10:19:52 -0600 (MDT) From: Scott Long <scottl@freebsd.org> To: sah@coraid.com Cc: arch@freebsd.org Subject: Re: AoE & driver tips Message-ID: <20040729094711.B32601@pooker.samsco.org> In-Reply-To: <20040728183344.ELWU1792.imf19aec.mail.bellsouth.net@coraid.com> References: <20040728183344.ELWU1792.imf19aec.mail.bellsouth.net@coraid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Jul 2004 sah@coraid.com wrote: > Hello, > > I'm in the process of writing a AoE disk/protocol driver for freebsd. > AoE (ATA over Ethernet) is used to access ATA devices attached directly to the Ethernet using the AoE registered Ethernet protocol type 0x88a2. I have already written a driver for linux 2.4 and 2.6 that makes AoE devices show up as local disks. I'm hoping to do the same for freebsd. I have some questions from my > initial perusal of the code. I guess the biggest question that you have to answer is whether you want to plug directly into the ATA framework or have your driver be a monolithic block driver. The ATA framework provides generic ATA command transforms and error handling and might be attractive for your needs. However, I have not read the AoE spec so I can't say for sure. Areas like error recovery might or might not be applicable to your needs. The downside to plugging into the ATA layer is that it is very centered on having very thin/simple hardware drivers underneath it. It seems to also be centered on the traditional ATA assumptions of discrete channels with a fixed number of drives that can or cannot do traditional DMA operations. I'm not sure how hard it would be to broaden its scope here. Doing something that crosses from the ATA layer to the network layer might also have some locking implications, but again I don't know for sure. ATA also seems to be on a bit of a rocky road for many people right now, so you might want to seriously investigate it before deciding. In any case, the API that you want to look at for plugging into it is nominally defined in the ata_pci_controller and ata_device structures. One other thing to note is that the ATA driver in 4.x isn't layered like it is in 5.x so plugging into it will be a bit harder. Writing a separate block driver isn't very hard, but it means that your user-visible disk devices will have unique names and not be part of the '/dev/adN' naming scheme. This usually isn't a big deal. Locking is also much simplier in this scheme. You do have to provide your own ATA command transformsi, enumeration/discovery, and error recovery, though. > I've been looking at the code in sys/dev/ata/ for tips on plugging into > the disk device layer. It appears that what I want is disk_create && > disk_destroy. How is the parameter "unit" related to device major & > minor? I don't see anywhere where major and minor are related to the > disk structure, though perhaps I'm just missing it. Do I need to > register a device major? disk_create() and disk_destroy() are block layer API calls that the ATA framework calls on behalf of the lower ATA hardware drivers. Major numbers are dynamically assigned in FreeBSD 5.x. For 4.x, you'll only need a unique major reservation if your driver winds up being a block driver. If it's an ATA driver then it'll use the ATA major/minor scheme. > > If a device fails or vanishes, can i just fail the outstanding bios and > disk_destroy it? How does freebsd do SMART on ata? I'd like to be able > to plug into this as well if the system uses it. I believe that there are some SMART monitoring tools in the ports tree (/usr/ports/sysutils/smartmontools looks promising), but there isn't anything like that integrated into the base system. > > Any other tips/comments about gluing together the disk & network would be appreciated. You might also consider plugging into the SCSI framework (called CAM on FreeBSD). There are many tradeoffs there, but the API is more flexible and is consistent between 4.x and 5.x. If neither frameworks appeal to you then doing a block driver would be the right choice. Block drivers are a bit more flexible in FreeBSD than they are in Linux, too. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040729094711.B32601>