Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Jan 2000 17:40:13 +0900
From:      "Daniel C. Sobral" <dcs@newsguy.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, Greg Lehey <grog@lemis.com>
Subject:   Re: Learning the FreeBSD Kernel
Message-ID:  <388C0FED.706330D0@newsguy.com>
References:  <200001231648.LAA53658@cs.rpi.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
Bill Maniatty wrote:
> 
> 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.

You won't have any trouble at all with basic driver installation. In
fact, this is driver skeleton, that can be templated (and used to... but
I don't know if we have newbus templates or not).

Notice that most developers use kld to develop their drivers. Not having
to recompile the kernel and reboot really helps. :-) There exists one
tutorial-style guide to writing kld's. It's a "hacking" guide to the use
of kld's as a way to introduce back-doors in FreeBSD, and though it's
somewhat "unclean" wrt to interface description, it's an effective
tutorial. I'm sure it can be found from FreeBSD's web site.

As a next step, I suggest writing "virtual" drivers, not bound to any
hardware. There are many such drivers in the tree. As a trivial example,
and a favorite of many, the screen savers.

The above will get you proficient with the basics of writing device
drivers, but still leave a lot out. Let's see...

> > Definately not an ethernet card. *g*
> > Seems no-one can keep up with Bill Paul in that aspect. =)
> 
> We probably could not compete :-), but we are interested in ethernet
> card drivers (at some point) and would like to learn.
> 
> > 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.

If we support ethernet cards on USB, I'd say it's pretty mature. :-)

Anyway, here is what virtual drivers won't teach: how to get resources,
which will vary from bus to bus, how to interact with some of the kernel
subsystems... How does one write a tun device? How does one write a
network device? How does one write a network protocol? How does one
write a CAM device (more than one type exist -- some virtual and some
not)? How does one write a bus device? When to write a bus (newpcm uses
a bus of it's own, if I'm not mistaken)?

These problems are mostly distinct from each other, and their usefulness
varies. Certainly, a tutorial covering newbus and the main bus types
(usb, isa, pci) would be useful and not too difficult to write. CardBus
and PCMCIA would be very useful, but we'll have to finish that first
:-). 

But it gets complicated from there on. Writing a tutorial on even a
subsection of CAM would be very time-consuming. I assume the same can be
said of network devices in general. It will probably not be viable to
cover more than one such subject, and their usefulness would be somewhat
restricted. On the other hand, it is precisely this kind of tutorial
that is mostly needed, since all of what I mentioned before can be dealt
with on the fly, just by copying source from existing devices.



Now... let me see if I can recall some of the gotcha's (notice that I
have never written a newbus device driver). Writing a device driver to
exotic devices, as long as you have the documentation for it, is really
simple. It's when you have to interact to kernel subsystems that
steepens the learning curve. Getting a MYDEVICE into memory is trivial.
Just steal the skeleton from the source of some existing device. Julian
had a device skeleton generator way back, I don't know if there is a
newbus equivalent or not.

As long as a device is just inb/outb (I seem to recall newbus have a
replacement for these), things are mostly trivial. Covering what you can
and cannot do in an interrupt context, the exact working of our spl*()
functions (not just theory, but the practice of when to use them and
when not to), transfering data to/from user space, setting up dma
transfers, and what exactly happens in a tsleep() (DURING the tsleep(),
mind you :) are the FAQs, I think. Also, how to create a kernel thread
to lighten the load on the interrupt handler (ie, queue work to be done
outside the interrupt context) would be very useful too, and it's not
too much black magic.

Documenting the available debugging tools and useful debugging
techniques would be mostly welcome. Aside from "how do I use the kernel
debugger", use of tools such as truss, and loading symbol tables to
kld's (see Greg Lehey's documentation on debugging vinum) would be
useful tutorials.

Once you got the above, and possibly created some useful driver
templates in the process, I'd say choose a subsystem, and start some
in-depth tutorial. Stay away from FS work, as our interfaces are bound
to change. CAM is very stable, and SCSI drivers are always useful, so
that's one possible field. Network devices would probably take less
time, though (that's a wild guess on my part, though).

--
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org

	"2 b or not to b" meaning varies depending on whether one uses the 79
or the 83 standard.



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?388C0FED.706330D0>