From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 05:25:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7455116A4CE; Wed, 20 Apr 2005 05:25:34 +0000 (GMT) Received: from mail.fci.fsu.edu (mail.fci.fsu.edu [128.186.195.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id E411D43D1F; Wed, 20 Apr 2005 05:25:33 +0000 (GMT) (envelope-from neuro@mail.fci.fsu.edu) Received: from mail.fci.fsu.edu (mail.fci.fsu.edu [127.0.0.1]) by mail.fci.fsu.edu (Postfix) with ESMTP id A501229216A; Wed, 20 Apr 2005 01:23:15 -0400 (EDT) Date: Wed, 20 Apr 2005 01:23:15 -0400 (EDT) From: neuro@mail.fci.fsu.edu To: Bill Paul In-Reply-To: <20050420052240.7EFAD16A4CF@hub.freebsd.org> Message-ID: References: <20050420052240.7EFAD16A4CF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 05:25:34 -0000 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@windriver.com | Wind River Systems > ============================================================================= > you're just BEGGING to face the moose > ============================================================================= > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >