Re: Modular ata chipsets data - FreeBSD

This is a discussion on Re: Modular ata chipsets data - FreeBSD ; I found the devel tree with a modulerized ATA subsystem in it, and just upgraded it to the latest greatest from -current. It can be found on http://deepcore.dk/pub/ATA as two files, ata- modules-diff that contains a diff for /sys/conf/files and ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Re: Modular ata chipsets data

  1. Re: Modular ata chipsets data

    I found the devel tree with a modulerized ATA subsystem in it, and
    just upgraded it to the latest greatest from -current.
    It can be found on http://deepcore.dk/pub/ATA as two files, ata-
    modules-diff that contains a diff for /sys/conf/files and ata-
    modules.tgz that is a replacement for /sys/dev/ata.
    This turns the chipset parts into a module for each vendor, and they
    are all compiled in as is, however they can be left out on a pr vendor
    basis (there are a few interdependencies though).
    I havn't written all the /sys/modules/ata/*/Makefiles that it would
    take to make it into loadable modules, but thats trivial todo.

    Now what I'd like to find good generic solutions to is:

    How to select the proper modules at config/compile time without
    drowning in "option ATA_BLA_BLA" in the config.

    How to automagically load the right modules when device probing takes
    place. It could be loading them all in turn and unloading those that
    didnt catch anything. I'm not aware of any ways to do this in the
    kernel, but I've been unattentive for the last many months, so it
    might have crept in

    Let me know how this works for you, I could very well be tempted to
    commit it to -current soonish as it makes some things easier to play
    with.

    PS: please keep me CC'd still, I dont read arch currently

    -S鷨en

    On 4Oct, 2008, at 19:57 , Oleksandr Tymoshenko wrote:

    > S鷨en Schmidt wrote:
    >> Hi
    >> (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.

    > Great, I'll wait for results of your work to hit svn.
    >
    >> PS: in your patch you suddenly got exclusive Copyright on the Intel
    >> and AHCI code, that will get you bad karma

    > Ha! I cheated by helping old ladies across the street and got
    > some extra karma to burn As I told - my vim is the one to be blamed,
    > these copyrights wasn't going to make it into svn commit anyway
    >
    >
    >> -S鷨en
    >> On 4Oct, 2008, at 4:17 , Oleksandr Tymoshenko wrote:
    >>> Hello -arch,
    >>>
    >>> I was playing with p4 mips2 branch catching up with recent
    >>> developments
    >>> and trying to reduce kernel size for MALTA configuration. At some
    >>> point
    >>> I ran into ata-chipset.c. This file contains all ATA chipsets
    >>> supported
    >>> by FreeBSD so it was a natural candidate for axing. I hacked small
    >>> proof-of-concept framework for pluggable ATA chipsets. The idea is
    >>> to
    >>> move all vendor-related code to separated modules (.c, not .ko),
    >>> register each during compile/link-time using ATA_CHIPSET macros
    >>> (utilizes DATA_SET for this purpose) and provide each chipset with
    >>> kernel config option. Something like this Warner did to miibus/*phy
    >>> about two years ago.
    >>>
    >>> So far I got only Intel vendor working (tested with Gxemul) and
    >>> would
    >>> like to know if it's worth to keep moving in this direction and what
    >>> possible pitfalls may appear.
    >>>
    >>> 90Kb is not that dramatical improvement , but it's better then
    >>> nothing
    >>> and code readability should be better after splitting 180K file into
    >>> several, IMHO.
    >>>
    >>> Patch: http://people.freebsd.org/~gonzo/emb...dular-ata.diff
    >>> don't mind copyrights, they're automatically inserted by vim.
    >>>
    >>> --
    >>> gonzo
    >>>

    >


    -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"


  2. Re: Modular ata chipsets data

    Sren Schmidt wrote this message on Sat, Oct 04, 2008 at 20:31 +0200:
    > How to select the proper modules at config/compile time without
    > drowning in "option ATA_BLA_BLA" in the config.


    Possibly use an include file that lists all of the options/devices,
    and then people who want to reduce it can remove it and put the
    respective lines in their config file directly, or turn them off
    through no prefix...

    --
    John-Mark Gurney Voice: +1 415 225 5579

    "All that I will do, has been done, All that I have, has not."
    _______________________________________________
    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"


  3. Re: Modular ata chipsets data

    On Saturday 04 October 2008 02:31:35 pm S鷨en Schmidt wrote:
    > I found the devel tree with a modulerized ATA subsystem in it, and
    > just upgraded it to the latest greatest from -current.
    > It can be found on http://deepcore.dk/pub/ATA as two files, ata-
    > modules-diff that contains a diff for /sys/conf/files and ata-
    > modules.tgz that is a replacement for /sys/dev/ata.
    > This turns the chipset parts into a module for each vendor, and they
    > are all compiled in as is, however they can be left out on a pr vendor
    > basis (there are a few interdependencies though).
    > I havn't written all the /sys/modules/ata/*/Makefiles that it would
    > take to make it into loadable modules, but thats trivial todo.
    >
    > Now what I'd like to find good generic solutions to is:
    >
    > How to select the proper modules at config/compile time without
    > drowning in "option ATA_BLA_BLA" in the config.


    What happens with mii is that you have a choice, you can either use 'device
    miibus' in which case you get all of the various drivers and the
    infrastructure, or you can use 'device mii', 'device rlphy', etc. if you wish
    to take a more fine-grained approach. Similarly, there is a miibus.ko that
    just depends on all the sub-drivers so you can still do 'kldload miibus.ko'
    to load all of them. I think this is probably a fine model as it will still
    load everything by default, but people who care about the space savings can
    trim things down as desired.

    --
    John Baldwin
    _______________________________________________
    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"


  4. Re: Modular ata chipsets data


    On 8Oct, 2008, at 23:43 , John Baldwin wrote:

    > On Saturday 04 October 2008 02:31:35 pm S鷨en Schmidt wrote:
    >> I found the devel tree with a modulerized ATA subsystem in it, and
    >> just upgraded it to the latest greatest from -current.
    >> It can be found on http://deepcore.dk/pub/ATA as two files, ata-
    >> modules-diff that contains a diff for /sys/conf/files and ata-
    >> modules.tgz that is a replacement for /sys/dev/ata.
    >> This turns the chipset parts into a module for each vendor, and they
    >> are all compiled in as is, however they can be left out on a pr
    >> vendor
    >> basis (there are a few interdependencies though).
    >> I havn't written all the /sys/modules/ata/*/Makefiles that it would
    >> take to make it into loadable modules, but thats trivial todo.
    >>
    >> Now what I'd like to find good generic solutions to is:
    >>
    >> How to select the proper modules at config/compile time without
    >> drowning in "option ATA_BLA_BLA" in the config.

    >
    > What happens with mii is that you have a choice, you can either use
    > 'device
    > miibus' in which case you get all of the various drivers and the
    > infrastructure, or you can use 'dvice mii', 'device rlphy', etc. if
    > you wish
    > to take a more fine-grained approach. Similarly, there is a
    > miibus.ko that
    > just depends on all the sub-drivers so you can still do 'kldload
    > miibus.ko'
    > to load all of them. I think this is probably a fine model as it
    > will still
    > load everything by default, but people who care about the space
    > savings can
    > trim things down as desired.


    Yep, I thought about that one too and I like the idea. I'm close to
    having it all sorted out and ready to commit, just need to polish
    things up a bit. I should make no functional changes just restructure
    chipset code into seperate files.

    -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"


  5. Re: Modular ata chipsets data

    on 09/10/2008 00:43 John Baldwin said the following:
    > What happens with mii is that you have a choice, you can either use 'device
    > miibus' in which case you get all of the various drivers and the
    > infrastructure, or you can use 'device mii', 'device rlphy', etc. if you wish
    > to take a more fine-grained approach. Similarly, there is a miibus.ko that
    > just depends on all the sub-drivers so you can still do 'kldload miibus.ko'
    > to load all of them. I think this is probably a fine model as it will still
    > load everything by default, but people who care about the space savings can
    > trim things down as desired.


    Sorry for hijacking the thread but is this documented anywhere?
    On RELENG_7 system I couldn't find the above info in NOTES and
    miibus(4), only device miibus is referred to.

    --
    Andriy Gapon
    _______________________________________________
    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"


  6. Re: Modular ata chipsets data

    On Thu, Oct 09, 2008 at 02:51:33PM +0300, Andriy Gapon wrote:
    > on 09/10/2008 00:43 John Baldwin said the following:
    > > What happens with mii is that you have a choice, you can either use 'device
    > > miibus' in which case you get all of the various drivers and the
    > > infrastructure, or you can use 'device mii', 'device rlphy', etc. if you wish
    > > to take a more fine-grained approach. Similarly, there is a miibus.ko that
    > > just depends on all the sub-drivers so you can still do 'kldload miibus.ko'
    > > to load all of them. I think this is probably a fine model as it will still
    > > load everything by default, but people who care about the space savings can
    > > trim things down as desired.

    >
    > Sorry for hijacking the thread but is this documented anywhere?
    > On RELENG_7 system I couldn't find the above info in NOTES and
    > miibus(4), only device miibus is referred to.


    I've once tried this. Adding modules for xxxphy is easy, but I found it
    rather difficult to isolate which NIC needs to depend on which phy (for
    example, you'll want if_rl to depend on rlphy - but this isn't obvious
    for all NIC/PHY combinations)

    Regards,

    --
    Rink P.W. Springer - http://rink.nu
    "Anyway boys, this is America. Just because you get more votes doesn't
    mean you win." - Fox Mulder
    _______________________________________________
    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