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: Scott Long: "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:39:38 -0700
To: Warner Losh <imp@bsdimp.com>

    Warner Losh wrote:

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

    yes, it passively listens to requests for firmware.

    > It listens for
    > events and then runs programs.

    Excellent! Exactly that is needed!

    > It is not there to interact with the
    > kernel in synchronous manner. Everything is queued and there's
    > deliberately no meachanism for a reply.
    >
    > There's also no reason to have a third party involved to load the
    > module.

    Maybe you want a program that can on-the-fly patch the wi firmware?

    > None of the other automatic kldload parts of the kernel need
    > this. Why is driver firmware any different?

    Why hack the kernel module loader?

    > You can easily define
    > the interface to be load module "$driver-fw-$type" and the driver can
    > take care of the sprintf to fill in the string. A carefully chosen
    > interface here can help eliminate the extra layers of complexity. How
    > the heck would devd know how to convert the particular key into
    > something meaningful?

    Maybe via some sort of configuration file? I thought that devd had one
    of those. Guess I'm wrong?

    > How would concentrating the quirks of all
    > possible drivers in devd be better than localizing them in the driver
    > itself?

    Why put a lot of complexity into a program that corrupts your data when
    it has a bug?

    Scott
    _______________________________________________
    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: Scott Long: "Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h"

    Relevant Pages

    • Re: HAL/freebsd architecture
      ... :> think that these would be useful for many more applications than just hald. ... This is so that we could preserve current devd functionality ... :> either already done in kernel as well or it better be done in kernel. ... asked developers include extending the ldev driver (luigi's Linux device ...
      (freebsd-arch)
    • Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h
      ... scottl> Scott Long ... scottl> can ask for a module via a particular key, devd maps the key to a file ... scottl> via its config file and loads it into kernel space as a KLD, ... scottl> or hard-coding knowledge of the filesystem layout into the driver. ...
      (freebsd-arch)
    • Re: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwi
      ... >scottl> can ask for a module via a particular key, devd maps the key to a file ... >scottl> via its config file and loads it into kernel space as a KLD, ... Why not just make the loader able to load an arbitrary ...
      (freebsd-arch)
    • Re: HAL/freebsd architecture
      ... :> think that these would be useful for many more applications than just hald. ... This is so that we could preserve current devd functionality ... :> either already done in kernel as well or it better be done in kernel. ...
      (freebsd-arch)
    • HAL/freebsd architecture
      ... think that these would be useful for many more applications than just hald. ... This is so that we could preserve current devd functionality ... media checking/polling would probably have to go ... either already done in kernel as well or it better be done in kernel. ...
      (freebsd-arch)