Date: Mon, 24 Jan 2000 12:39:21 +0800 From: Greg Lehey <grog@lemis.com> To: Bill Maniatty <maniattb@cs.rpi.edu> Cc: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>, FreeBSD-doc@FreeBSD.ORG, maniatty@cs.albany.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Learning the FreeBSD Kernel Message-ID: <20000124123920.F2643@mojave.worldwide.lemis.com> In-Reply-To: <200001231648.LAA53658@cs.rpi.edu>; from maniattb@cs.rpi.edu on Sun, Jan 23, 2000 at 11:48:39AM -0500 References: <20000123125439.A20851@daemon.ninth-circle.org> <200001231648.LAA53658@cs.rpi.edu>
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.
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 :-)
>> You could try usb devices and contact Nick Hibma for his expertise on
>> that area.
>
> How mature is the USB driver technology? If it is pretty
> preliminary we may wish to visit that later. Please recall that we
> are on a learning curve here.
I've been meaning to look at USB stuff too. So far, I haven't been
brave enough.
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.
Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers
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?20000124123920.F2643>