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=F8ren 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 =20 >> 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 =20= >> to go >> for vendor supplied modules as well. I have a least 2 vendors that =20= >> are >> looking into that way of providing support for new chipsets. For a =20= >> small >> kernel you just load the module(s) you need and voila. >> >> I have VIP in that direction, but its not finished yet, but =20 >> 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 =20 >> 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 =20= > ATA > driver so there is a generic ATA logic layer, clearly separate from =20= > controller > specific parts and bus attachments like PCI etc.? Actually it is allready done that way, at least to the extent that the =20= device in question has to look like or be able to be modelled like an =20= ATA device. ata-isa.c ata-card.c ata-cbus.c ata-pci,c are all different bus =20 "adaptors" that just interact with different connection methods for =20 generic ATA devices, and presents them in a generic way to the ATA =20 "core" below. ata-all.c ata.-queue.c ata-lowlevel,c ata-dma.c are the "core" of the =20= ATA functionality, machinery that knows the ATA/ATAPI protocol and how =20= to deal with it. ata-disk.c atapi-cd.c atapi-fd.c atapi-tape.c are device drivers for =20 the different types of ATA/ATAPI devices. They know how to talk to the =20= 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 =20 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 =20= as if they where connected to an ATA bus, utilizing ATA's flexibility =20= to cope with just about anything that smells of ATA. > Such a well structured approach would greatly benefit embedded =20 > systems at > least, which very often have an ATA/SATA controller hanging directly =20= > on some > local bus; in environments like this using our current ATA code is =20 > 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-=20 yourbus.c" ala the others mentioned above to tie you given HW setup =20 into ATA, and you're golden. Let me know a little more about you given HW, and I'll help you out =20 doing this. BTW, I have one of these WD MyBook World lying around in pieces, any =20 chances someone has played with getting FreeBSD onto one of those (it =20= runs linsux from factory). Would make a nice platform to play with =20 ARM, and I'm sure it needs ATA support to work :) -S=F8ren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06D9EA2E-3EB2-4F77-8AE8-CD70E6D46444>