Date: Thu, 13 Aug 1998 01:30:54 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: grog@lemis.com (Greg Lehey) Cc: edebruin@iname.com, hackers@FreeBSD.ORG Subject: Re: developing device drivers Message-ID: <199808130530.BAA27253@skynet.ctr.columbia.edu> In-Reply-To: <19980813124831.D1147@freebie.lemis.com> from "Greg Lehey" at Aug 13, 98 12:48:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Greg Lehey had to walk into mine and say: > On Wednesday, 12 August 1998 at 16:42:09 +0000, eT wrote: > > Greets, > > > > Thanks to all the guys out there who are so willing to help. One day > > when I'm big I want to be like you guys :) > > > > I have read 'Writing a Unix Device driver 2nd edition' and have read > > 'FreeBSD device driver's guide' and I now need to take the plunge and > > start developing/coding. > > > > I was wondering if there was a way to develop & test & debug a device > > driver before linking it into the kernel .. i know it sorta doesn't make > > sense, but as i said i was wondering... > > Sure. Make it an LKM. It's a lot easier to debug, though there are a > couple of things you need to know to get the symbols for the kernel > debugger. > > There's some stuff on this subject in the online handbook. I'm also > planning to write some stuff up about the testing environment. I second this. If you look in /usr/share/examples, you'll find a couple of sample LKMs written by Terry Lambert. I hijacked the syscall example from here and used it a lot to experiment with the XL driver. What I did, being in a rush one day, was to wrap the whole of the driver code inside the module by simply #including the whole C module into the misccall.c file. This allows me to add bits and pieces to the misccall() routine that can invoke the functions in the driver code and report the results. You actually end up with two instances of the driver in core; the one linked in the kernel and the one wrapped inside the LKM, but the functions are all declared static so the LKM can only call its own copies of the routines. This is most useful for testing things like EEPROM and register access routines. For PCI devices, you need to write at least a stub driver to do the required PCI device setup and determine the iobase address where the devices has been configured. It's also a good idea to register an interrupt routine. Once you set up an ifnet structure and do an ether_attach(), the LKM can grab a pointer to the interface's ifnet structure by calling the ifunit() function. The main idea here is to get the kernel to recognize the device and allow you to learn its configuration information, as well as making sure that the right bits are set in the PCI command register (iospace enabled, memory mapped space enabled, bus master enabled). In fact, you can probably develop most of the driver this way. There are a couple of functions that have to be specified in the ifnet structure (transmission start, adapter init, adapter stop, ioctl, etc...) which are called from higher protocol layers, but you can stub these out in such a way that they do nothing normally but can be re-mapped by your LKM initialization routine so that they call into the routines loaded with the LKM. You also have to unmap the routines when the LKM is removed; once the LKM is unloaded, trying to jump to the addresses where its routines used to reside will cause a panic. You can also panic the system by making a coding error in the LKM. You could probably extend this somewhat to create a generic mechanism for implementing all PCI ethernet drivers as LKMs, but then you'd have to come up with a way to implement diskless booting (you can't load the driver LKM until you mount the rootfs, but you can't mount the rootfs until you load the driver LKM, but you can't load the driver LKM until you mount the rootfs, but...). -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808130530.BAA27253>