> 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 ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
