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

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

> Collisions during driver loading are avoided by having windrv_stub.c
> obtain a unique name for the DRIVER_MODULE() macros and friends.
> As for network interfaces, they will all end up named ndisX. In my testing,
> I put an Atheros card and Intel 2200BG card in the same system.
> If I kldload w22n51_sys.ko first, ndis0 is created which maps to
> the Intel card, and then loading ar5211_sys.ko creates ndis1, which
> maps to the Atheros card. If I load the modules in the reverse order,
> ndis0 becomes the Atheros card and ndis1 becomes the Intel card.
> During bootstrap, order depends on the PCI bus probe order.
> 
> Note that a kldload foo_sys.ko will automatically force a load
> of ndis.ko and if_ndis.ko.
> 
> I had to rig things such that unloading one of the converted modules
> forces a detach of all devices associated with that module. Failing
> to do this would leave a network interface in place that depends
> on a non-existent .SYS image. I was hoping to find a way to trick
> the module dependency mechanism into handling this for me, but 
> came up empty. So instead, windrv_unload() hunts down all the device
> handles for any dependent interfaces and does an explicit
> device_detach() on them.
>  
> > > The end result is that installing a Windows driver should be as simple
> > > as:
> > >
> > > - run the script
> > > - give it your foo.inf and foo.sys files when it asks you
> > > - it spits out a foo_sys.ko module and you kldload it
> > > - the end
> > 
> > Sounds much nicer :)
> 
> I put a snapshot of the code (relative to -current) at:
> 
> http://www.freebsd.org/~wpaul/ndis_snap.tar.gz
> 
> The script and stub file are in the usr.sbin/ndiscvt directory. The
> script still needs a bit of work, but handles most basic cases.
> 
> > > You still end up needing the C compiler, objcopy, ndiscvt and (optionally)
> > > iconv, but the script automates the use of all these tooks and explains
> > > to the user what's going on while it's working.
> > 
> > It's certainly simpler than the current state of afairs and unless the kernel 
> > NDIS grows the ability to directly read .sys & .inf files from your disk 
> > (which would be very cool :) it's about a simple as it's going to get..
> 
> Putting a .INF parser in the kernel would not be cool at all. Kernels
> are for managing hardware and herding applications, not parsing text
> files.
>  
> > > - What should the script be called? wintobsd.sh sounds kind of lame.
> > 
> > encappe
> > win2elf
> > pe2elf
> 
> Hm... have to think about these.
> 
> -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
> =============================================================================
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"