Modular ata chipsets data

[Rafal Jaworowski]

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.?

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.

Rafal