Skip site navigation (1)Skip section navigation (2)
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-doc" 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>