Date: Mon, 24 Jan 2000 00:11:08 -0500 From: Bill Maniatty <maniattb@cs.rpi.edu> To: Greg Lehey <grog@lemis.com> Cc: Bill Maniatty <maniattb@cs.rpi.edu>, Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>, FreeBSD-doc@FreeBSD.ORG, maniatty@cs.albany.edu, freebsd-hackers@FreeBSD.ORG, maniattb@cs.rpi.edu Subject: Re: Learning the FreeBSD Kernel Message-ID: <200001240511.AAA68097@cs.rpi.edu> In-Reply-To: Your message of "Mon, 24 Jan 2000 12:39:21 %2B0800." <20000124123920.F2643@mojave.worldwide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sunday, 23 January 2000 at 11:48:39 -0500, Bill Maniatty wrote: > > Hello Jeroen: > > Jeroen Ruigrok (in response to Greg Lehey and myself): > > > >> -On [20000123 11:11], Greg Lehey (grog@lemis.com) wrote: > >>>> 2) Choose a non-essential device with a simple preexisting driver. > >>>> 3) Remove all trace of the driver from the kernel source. > >>>> 4) Reapply the changes used to install the driver (perhaps one step at a time). > >>>> We could suggest some simple sanity checks to support stepwise refinement. > >>> > >>> (1) and (2) are a good start. You don't need to remove the old > >>> driver; it would in fact make it easier for debugging purposes if it > >>> remained. Instead, choose another major number and name, and write a > >>> new driver. This procedure is definitely *not* documented, but it's > >>> the way we introduce new drivers, and I think a couple of other people > >>> who have done it would be pleased to help. > >> > >> *nod* There are certainly people who are be able and willing to help. > >> > >>> A possibly better alternative is to find a device which isn't > >>> currently supported by FreeBSD and write a driver for it. This would > >>> have the advantage that the work would also be a contribution to > >>> FreeBSD. The question that I can't answer here is: what would be an > >>> appropriate device? > > > > First we want to get the mechanism of driver installation down, then > > try our hands at writing our own driver. I fear that if we roll our > > own driver software we may find that if we have errors (not that we > > ever have errors mind you :-) we may not be able to isolate the > > cause. This is why I was leaning towards reinstalling a working > > driver first. > > There are two almost completely separate issues in writing drivers: > > 1. Writing the code to deal with the device. Having good vendor > documentation helps here. > > 2. Fitting this code into the BSD framework. Having good OS > documentation helps here. Good point, while I would like to see more vendors step up and document their device interfaces, that part is not within grasp. > I can't agree with Mike Smith that reading the code is adequate. It > certainly doesn't apply to newcomers, but it doesn't even apply to > seasoned hackers like Mike: the BSD style doesn't provide for adequate > comments, and so what you see from the code is mainly tactics, not > strategy. For the fun of it, go through the sources in > /usr/src/sys/pci and try to identify the hardware which each driver > supports. The newer ones are very good in this respect, but I'd guess > there would be between 10% and 20% of the files where you will be left > wondering what they do. Read the code and you'll see how they do it, > but you may find that that isn't enough for you :-) Thanks Greg, these remarks confirm my suspiscions. [deletia] > I do think that the idea of taking an existing driver and cloning it > is a good one. Maybe we can identify an old and mouldy one which > needs rewriting. I've heard things about the floppy disk driver, but > I'm not sure that it hasn't already been done, though the code > suggests it's pretty old. I think that might be a good idea, but right now we might be better served by simply playing with a modern driver and what the installation process is. Again we want to understand how to install a driver and where it interfaces with the Kernel. But the idea of updating an older driver to the modern structure is attractive. Greg, thanks for your constructive input. Regards: Bill Maniatty 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?200001240511.AAA68097>