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

Bill Paul,

it's good to see that you're still working on this project.  Do let me 
know if you need any assistance.

--sahil

On Wed, 20 Apr 2005, Bill Paul wrote:

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