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

From: <neuro_at_mail.fci.fsu.edu>
Date: Wed, 20 Apr 2005 01:23:15 -0400 (EDT)
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"
>
Received on Wed Apr 20 2005 - 03:25:34 UTC

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