Modular ata chipsets data

[Søren Schmidt]

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