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

> On Wed, 20 Apr 2005 08:26, Bill Paul wrote:
> > The objcopy(1) trick basically produces an ELF file that has the
> > Windows .SYS file encapsulated with in it. Two symbols are created
> > to denote the start end end of the image so that it can be loaded later.
> > The windrv_stub.o module linked with the Windows image provides a
> > small FreeBSD modevent handler that hooks the driver into Project
> > Evil and eventually causes a bus-reprobe. This means that all you
> > have to do is kldload this one module into the kernel, and presto!
> > a new ndisX networking interface appears.
> 
> What about if you want to use >1 NDIS driver? How will it avoid symbol name 
> collisions?

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
=============================================================================