cvs commit: src/sys/modules Makefile
brooks at one-eyed-alien.net
Tue Aug 3 10:05:43 PDT 2004
On Tue, Aug 03, 2004 at 12:39:06PM -0400, John Baldwin wrote:
> On Monday 02 August 2004 05:51 pm, Nate Lawson wrote:
> > Mark Murray wrote:
> > > Brooks Davis writes:
> > >>IMO this is a module system bug not a bug in any given module. There's
> > >> no good reason for the system to succeed at loading a module that's
> > >> already there regardless of how it got there. I don't understand the
> > >> module system well enough to know where the bug lies, but I believe the
> > >> DECLARE_MODULE statement provides more then enough information to avoid
> > >> duplicates.
> > >
> > > I'm looking to see if MODULE_VERSION() may fix this.
> > The case where mem is compiled into the kernel and then an attempt is
> > made to load it as a module needs to be detected by looking for an
> > instance of the devclass. See how acpi/legacy co-exist. This is not
> > just a problem with the same module being loaded multiple times.
> mem is a dev_t aka struct cdev *, not a device_t. There is no devclass.
Similarly, where I've seen this problem is pseudo network interfaces
which are nothing but ifnet entries. This is why I think we need to
handle this in the module layer and stop requring hack in every driver.
I think peter's module code might fix some of this since I think we'll
get module registrations for static modules.
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20040803/1ad4b061/attachment.bin
More information about the cvs-src