From owner-freebsd-hackers Sun Jan 23 21:11:29 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id DF00C15005; Sun, 23 Jan 2000 21:11:21 -0800 (PST) (envelope-from maniattb@cs.rpi.edu) Received: from cs.rpi.edu (maniattb@dishwasher.cs.rpi.edu [128.213.8.31]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id AAA68097; Mon, 24 Jan 2000 00:11:10 -0500 (EST) Message-Id: <200001240511.AAA68097@cs.rpi.edu> X-Mailer: exmh version 2.0.1 12/23/97 To: Greg Lehey Cc: Bill Maniatty , Jeroen Ruigrok/Asmodai , FreeBSD-doc@FreeBSD.ORG, maniatty@cs.albany.edu, freebsd-hackers@FreeBSD.ORG, maniattb@cs.rpi.edu Subject: Re: Learning the FreeBSD Kernel In-reply-to: Your message of "Mon, 24 Jan 2000 12:39:21 +0800." <20000124123920.F2643@mojave.worldwide.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Jan 2000 00:11:08 -0500 From: Bill Maniatty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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