Subject: Re: PCI device driver for sparc, sparc64, and i386
To: Steven Grunza <steven_grunza@ieee.org>
From: Bill Studenmund <wrstuden@zembu.com>
List: tech-kern
Date: 02/06/2001 17:08:24
On Tue, 6 Feb 2001, Steven Grunza wrote:
> I'm not sure if this is the correct list for this question but:
It is. :-)
> I plan on writing a device driver for a PCI card. I would like the same
> source to work on sparc, sparc64, and i386. Are there any issues betwen
> the 32-bit sparc and i386 and the 64-bit sparc64 of which I should be
> aware? I'm expecting to be calling hton and ntoh to deal with the endian
> problems...
Actually as others note, you want htole{32,64} and le{32,64}toh - pci is
little endian. Also, you only need these operations when manipulating data
in structures DMAd to the device. The bus_space routines will take care of
this for direct access.
Also, the 32-bit sparc is SBus, isn't it? Does the chip change operating
modes there? i.e. does it actually act big-endian? Some of the SCSI chips
available both for PCI and SBus have hit this, and should be a bit of
prior art.
> I've done pseudo-drivers for NetBSD before but this is the first "real"
> driver I've attempted. I'll probably need a header file for things private
> to the driver and one for things public to the users of the driver. Where
> should these two files go and is there a standard naming convention for
> them? I seem to recall X11 using a capital P at the end of the Public
> header....
Others have commented on this.
> If I don't hear otherwise, I'll probably try:
>
> /usr/include/jaguar.h for the public file (the board is called a jaguar)
> /usr/include/sys/jag.h for the driver's private file
>
> Thanks in advance....
As others have noted, the naming scheme is syssrc/dev/ic/foo.c,
syssrc/dev/ic/fooreg.h, syssrc/dev/ic/foovar.h, syssrc/dev/pci/foo_pci.c,
and syssrc/dev/sbus/foo_sbus.c.
In general, the driver's private file (foovar.h) is NOT installed into
user space. Often the fooreg.h files are, but you don't necessarily have
to. A syssrc/dev/ic/foo.h file might make sense. Have it contain all
elements of the userland interface (ioctls, structures passed in & out,
etc.). That is ALL that needs to be installed in userland. :-)
Take care,
Bill