Re: Modular ata chipsets data - FreeBSD

This is a discussion on Re: Modular ata chipsets data - FreeBSD ; S鷨en 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Modular ata chipsets data

  1. Re: Modular ata chipsets data

    S鷨en 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
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  2. Re: Modular ata chipsets data

    On 4Oct, 2008, at 20:34 , Rafal Jaworowski wrote:

    > S鷨en 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鷨en




    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


+ Reply to Thread