cvs commit: src/sys/dev/digi digi.c src/sys/kern kern_linker.c subr_firmware.c src/sys/sys linker.h

Brian Somers brian at Awfulhak.org
Sun Feb 18 13:28:50 UTC 2007


On Thu, 15 Feb 2007 21:01:57 +0100 Max Laier <max at love2party.net> wrote:
> On Thursday 15 February 2007 20:49, Luigi Rizzo wrote:
> > luigi       2007-02-15 19:49:27 UTC
> >
> >   FreeBSD src repository
> >
> >   Modified files:        (Branch: RELENG_6)
> >     sys/dev/digi         digi.c
> >     sys/kern             kern_linker.c subr_firmware.c
> >     sys/sys              linker.h
> >   Log:
> >   MFC kern_linker.c 1.133 and related changes:
> >
> >   - push Giant into linker_reference_module();
> >   - introduce linker_release_module(), which also takes care of
> >     proper locking.
> >
> >   The latter also fixes a missing mtx_loc/unlock in subr_firmware.c .
> >
> >   Apparently, digi.c is the only external client of
> > linker_reference_module() which is a bit suspicious - perhaps dev/digi/
> > could make with a bit of review from someone knowledgeable to check how
> > the function is used, and whether it could be replaced by something
> > else.
> 
> I have a version of digi(4) in perforce that uses firmware(9).  I couldn't 
> find testers, but with a bit of review this should be committable 
> nonetheless.
>  
> http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/mlaier/firmware/sys/dev/digi/&HIDEDEL=NO
> 
> >   Revision   Changes    Path
> >   1.58.2.3   +3 -3      src/sys/dev/digi/digi.c
> >   1.117.2.2  +31 -1     src/sys/kern/kern_linker.c
> >   1.1.2.4    +1 -3      src/sys/kern/subr_firmware.c
> >   1.39.2.2   +8 -0      src/sys/sys/linker.h
> 
> -- 
> /"\  Best regards,                      | mlaier at freebsd.org
> \ /  Max Laier                          | ICQ #67774661
>  X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
> / \  ASCII Ribbon Campaign              | Against HTML Mail and News

I could probably do some testing here - I have some digi
cards (although only one PCI one AFAIR!!).

I originally added linker_reference_module() because I
wanted to be able to dynamically load a module from
another module, or take a reference to it if it's
already there.  This was a good way to load/unload the
different firmware types after figuring out what the
card type is.

If firmware(9) avoids this necessity, I'm all for doing
away with linker_reference_module().

-- 
Brian Somers                                          <brian at Awfulhak.org>
Don't _EVER_ lose your sense of humour !               <brian at FreeBSD.org>


More information about the cvs-all mailing list