Date: Wed, 20 Apr 2005 05:22:40 +0000 (GMT) From: wpaul@FreeBSD.ORG (Bill Paul) To: doconnor@gsoft.com.au (Daniel O'Connor) Cc: freebsd-current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input Message-ID: <20050420052240.7EFAD16A4CF@hub.freebsd.org> In-Reply-To: <200504201221.39355.doconnor@gsoft.com.au> from "Daniel O'Connor" at "Apr 20, 2005 12:21:38 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> 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@windriver.com | Wind River Systems ============================================================================= <adamw> you're just BEGGING to face the moose =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050420052240.7EFAD16A4CF>