freebsd-skq/share/examples/drivers
Warner Losh 6715fca911 o Add cardbus support (use pci attachment for now)
<bde>
o Add comments in some places to clarify some points.
o Don't typedef sc_p.  This isn't usually done in the drivers and may
  cause problems in teh future if C goes the C++ route of requiring
  one and only one definition for each and every type.  Instead use
  the current convetion of expanding struct ${1}_softc * inline needed.
o change some comments to be more style(9)-like.
o Define and use DEV2SOFTC to encapsulate storing/getting softc from a
  dev_t.  This also takes care of the missing cast from the examples.
o Define and use DEVICE2SOFTC, similar to DEV2SOFTC for getting the
  softc from a device_t.
</bde>

We still should have this generate foo_{isa,pci,pccard,cardbus,eisa}.c
and foovar.h from templates of some sort, but I was too lazy to do
that in this commit.  I did document it in the comments, however.

Note: bde-like corrections made with the help of my my portable
plastic bde icon.  Results with the real bde may vary with use.
2000-12-18 21:08:53 +00:00
..
make_device_driver.sh o Add cardbus support (use pci attachment for now) 2000-12-18 21:08:53 +00:00
make_pseudo_driver.sh $Id$ -> $FreeBSD$ 1999-08-28 00:22:10 +00:00
README Fix typo 1998-01-15 13:42:28 +00:00

Sat Feb  1 23:30:12 PST 1997 <Julian Elischer>

These files are shell scripts.

They will, when run, create an example skeleton driver
for you. You can use this driver as a starting point for
writing drivers for your own devices. They have all the hooks needed
for intiialisation, probing, attaching, as well as DEVFS
node creation. They also create sample ioctl commands and a sample
ioctl definition .h file in /sys/sys. In other words they are fully
functional in a 'skeleton' sort of a way. They support multiple devices
so that you may have several of your 'foobar' devices probed and atached
at once.

I expect that these scripts will improve with time.

At present these scripts also link the newly created driver into
the kernel sources in /sys. Possibly a better way would be
to make them interactive. (and ask what kernel tree to use as well as
a name for the driver.).

There are presently two scripts.
One for making a real device driver for ISA devices, and 
one for making a device driver for pseudo devices (e.g. /dev/null).
Hopefully they will be joined by similar scripts for creating
skeletons for PCI and EISA devices as well.

Give them a single argument: the name of the driver.
They will use this given name in many places within the driver,
both in lower and upper case form.  (conforming to normal usage).

The skeleton driver should already link with the kernel 
and in fact the shell script will compile a kernel with the new 
drive linked in..  The new kernel should still be 
runnable and the new driver should be
fully callable (once you get your device to probe).
You should simply edit the driver and continue to use
'make' (as done in the script) until your driver does what you want.

The driver will end up in /sys/i386/isa for the device driver script,
and in /sys/dev for the pseudo driver script.