Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h

From: Scott Long (scottl_at_samsco.org)
Date: 11/21/05

  • Next message: Warner Losh: "Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h" 
    Date: Mon, 21 Nov 2005 11:03:56 -0700
To: Damien Bergamini <damien.bergamini@free.fr>

    Damien Bergamini wrote:

    > I don't like the idea of keeping the firmware in kernel memory.
    > It's a rather big file (~200KB).
    > And there is one for each operating mode (BSS, IBSS, monitor).
    >
    > The second reason why I don't like KLDs is because they require
    > user intervention and users must know which KLD to load for the
    > mode they want to operate in. And if you put all firmwares in
    > the same KLD, you end up with a big fat 1MB file.
    >

    The isp driver knows how to unload the ispfw module after it's done
    with it, so it doesn't stay resident in memory.

    > I won't go back to anything based on iwicontrol. People simply
    > don't know how to use it. Trust me. There is not a single day
    > where I don't get email from people complaining about it.

    I would be nice to have a single interface for loading data into the
    kernel from within the kernel, but there are complicating factors. On
    one side you have storage drivers like isp that need firmware in order
    to run (yeah, the isp hardware does have a basic firmware load, but it's
    pretty much useless), therefore you can't wait until the filesystem is
    available. On the other side you have devices that need to load fairly
    arbitrary data files, but only after boot.

    Loading files into the kernel manually has all sorts of problems. VFS
    is very hard to work with in its 'raw' API form because just about
    every operation has locking side effects that are hard to predict. A
    vput() call might simply lower the refcount on a vnode, or it might
    wind up calling VOP_INACTIVE and going into the bufcache. It's hard to
    handle this correctly, and it's it's not something that should be
    duplicated all over the kernel. I know that Windows and Linux have
    kernel APIs for reading files, but it's simply not a good idea to do it.
    Also, putting hardcoded paths into the driver is very unmaintainable.

    I guess my vote would be to have a devd mechanism where the kernel
    can ask for a module via a particular key, devd maps the key to a file
    via its config file and loads it into kernel space as a KLD, and then
    the kernel unloads the KLD when its done with it. For things like isp,
    nothing would change, and for iwi you'd get a reliable way of getting
    bits into the kernel that doesn't require messing with the VFS layer
    or hard-coding knowledge of the filesystem layout into the driver.

    Scott

    >
    > Damien
    >
    > | > Or have the firmware be embedded in a KLD, like ispfw.
    > |
    > | I think I've now been repeated by everyone in the conversation. :)
    > |
    > | So maybe it's time to solve this? Move discussion to arch@?
    > |
    > | --
    > | Nate
    >

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

  • Next message: Warner Losh: "Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h"

    Relevant Pages