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

From: Bill Paul (wpaul_at_FreeBSD.ORG)
Date: 04/20/05

  • Next message: Bill Paul: "Re: New driver loading scheme for Project Evil, need input" 
    To: rizzo@icir.org (Luigi Rizzo)
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@windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Bill Paul: "Re: New driver loading scheme for Project Evil, need input"

    Relevant Pages

    • Re: 7.1-RC2: link_elf: symbol cp_time undefined
      ... kldload: can't load linprocfs: No such file or directory ... Did you compile your kernel from scratch? ... I would think it's a lack of Linux support built into the updated kernel. ...
      (freebsd-stable)
    • Re: 4.9 KLDload error
      ... >>kldload should give more error information on what function it failed to load. ... >the kernel linker will send debugging output to the system console. ... I will look into it to see what causes this compile problem. ...
      (freebsd-hackers)
    • Re: SCO binary compatibilkity
      ... kldload ibcs2_coff.ko ... >kernel and install by default? ... >relatively easy task to recompile a new kernel to enable compatibility? ... Outgoing mail is certified Virus Free. ...
      (freebsd-questions)
    • Re: New driver loading scheme for Project Evil, need input
      ... i don't understand the issue of name collisions though. ... > As for network interfaces, they will all end up named ndisX. ... > I put an Atheros card and Intel 2200BG card in the same system. ... > Putting a .INF parser in the kernel would not be cool at all. ...
      (freebsd-current)
    • Re: 7.1-RC2: link_elf: symbol cp_time undefined
      ... kldload: can't load linprocfs: No such file or directory ... Jan Henrik ... Did you compile your kernel from scratch? ...
      (freebsd-stable)