Date: Sat, 4 Oct 2008 23:05:51 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@FreeBSD.ORG> To: Rafal Jaworowski <raj@semihalf.com> Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>, freebsd-arch@FreeBSD.ORG Subject: Re: Modular ata chipsets data Message-ID: <06D9EA2E-3EB2-4F77-8AE8-CD70E6D46444@FreeBSD.ORG> In-Reply-To: <48E7B73A.2030507@semihalf.com> References: <48E6D21E.8040808@bluezbox.com> <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> <48E7B73A.2030507@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4Oct, 2008, at 20:34 , Rafal Jaworowski wrote: > Søren Schmidt wrote: >> (Please keep me CC'd as I do not normally read the list) >> >> Anyhow, what I would like to see is that the chipset support get >> moved >> into kernel modules, preferably auto-loadable when a given vendor is >> detected, but for starters that could be left out. This is the way >> to go >> for vendor supplied modules as well. I have a least 2 vendors that >> are >> looking into that way of providing support for new chipsets. For a >> small >> kernel you just load the module(s) you need and voila. >> >> I have VIP in that direction, but its not finished yet, but >> spiitting up >> things is pretty trivial for the most part, except a few gotchas here >> and there that will make at least autoloading a wee bit tricky. >> >> I guess the tedious part is to get all the code moved around into >> seperate files, how the actual compile/link/load should be done is a >> minor part that can be added when the seperaion is done. >> However, I do have most of that in place in a tree here, so thats >> more >> or less done already, I just need to pull out the right tree here and >> that part should be dealt with more or less. > > Apart from the above, have you got any plans towards refactoring the > ATA > driver so there is a generic ATA logic layer, clearly separate from > controller > specific parts and bus attachments like PCI etc.? Actually it is allready done that way, at least to the extent that the device in question has to look like or be able to be modelled like an ATA device. ata-isa.c ata-card.c ata-cbus.c ata-pci,c are all different bus "adaptors" that just interact with different connection methods for generic ATA devices, and presents them in a generic way to the ATA "core" below. ata-all.c ata.-queue.c ata-lowlevel,c ata-dma.c are the "core" of the ATA functionality, machinery that knows the ATA/ATAPI protocol and how to deal with it. ata-disk.c atapi-cd.c atapi-fd.c atapi-tape.c are device drivers for the different types of ATA/ATAPI devices. They know how to talk to the device, using the "core" routines from above to do transfers etc. ata-chipset.c is the collection of code that knows how to deal with specific controller related things, ie how to set a given transfer mode. ata-usb.c is somewhat special, as it lets certain USB devices show up as if they where connected to an ATA bus, utilizing ATA's flexibility to cope with just about anything that smells of ATA. > Such a well structured approach would greatly benefit embedded > systems at > least, which very often have an ATA/SATA controller hanging directly > on some > local bus; in environments like this using our current ATA code is > difficult > as there needs to be some fake PCI glue provided and other hacks. That should be very easy to setup, you just need to write an "ata- yourbus.c" ala the others mentioned above to tie you given HW setup into ATA, and you're golden. Let me know a little more about you given HW, and I'll help you out doing this. BTW, I have one of these WD MyBook World lying around in pieces, any chances someone has played with getting FreeBSD onto one of those (it runs linsux from factory). Would make a nice platform to play with ARM, and I'm sure it needs ATA support to work :) -Søren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06D9EA2E-3EB2-4F77-8AE8-CD70E6D46444>