Re: New driver loading scheme for Project Evil, need input

From: Bill Paul <wpaul_at_FreeBSD.ORG>
Date: Wed, 20 Apr 2005 16:12:22 +0000 (GMT)
> On Wed, Apr 20, 2005 at 05:22:40AM +0000, Bill Paul wrote:
> ...
> > > What about if you want to use >1 NDIS driver? How will it avoid symbol name 
> > > collisions?
> 
> i don't understand the issue of name collisions though.
> Assuming that things work in the same way as dlopen()
> (which seems to be the case according to the documentation)
> the symbols in the module that we kldload are not globally
> visible, but keyed by fileid and only accessible through
> kldsym(). So the collisions are only in the filenames that
> we kldload, not in the individual symbols.
> Then it suffices to rename the patched files...
> 
> 	cheers
> 	luigi

Part of the module build mechanism turns all symbols within a .ko
static, so they aren't visible to other modules unless they have
an explicit dependency (MODULE_DEPENDS()). For this case, it happens
that all of windrv_stub.c's code and data are declared static anyway,
so multiple foo_sys.ko modules can't collide with each other.

The only thing that is a problem is using MODULE_VERSION(foo, 1).
The kernel will complain if you try to load a module of type "foo,1"
when there's already a "foo,1" module present. This prevents you from
confusing the kernel by doing:

# kldload ./foo.ko
# cp foo.ko bar.ko
# kldload ./bar.ko

If foo.c has MODULE_VERSION(foo, 1) in it, then the kernel will know
that bar.ko is just another copy of foo.ko even though the file name is
different.

-Bill

--
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul_at_windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================
Received on Wed Apr 20 2005 - 14:12:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:32 UTC