[pci] Re: PCI Linux driver

[Andreas Bombe <andreas.bombe@munich.netsurf.de>]

On Thu, Jul 26, 2001 at 02:35:37PM +0200, Miha Dolenc wrote:
> Hello everyone!
> 
>     I have programmed one simple kernel interface for PCI device, which we
> will need, when PCI bridge project is finished. If anyone here knows about
> Linux kernel and device drivers ( I don't ), I would ask him/her to review
> sources and add, repair or comment on them.

I have knowledge in that area.  Comes with dealing with the ieee1394
subsystem in Linux, I guess :)

As far as I can see this is just a debug driver to test the PCI
interface, so I can't make that much sense of it without reading up on
the PCI spec.  I can comment on a few obvious errors.

The verify_area() call to verify user space pointers has not been
necessary since Linux 2.2 since the get_user() and put_user() macros are
fault save, you just have to check their return values to see if the
access had an error.

Which leads to the second serious bug, you are not using them.  You must
never directly dereference user space pointers since you don't know what
awaits at the other end.  Non-x86 architectures can have user space in a
different address space.  Even on x86 verify_area() doesn't allow you
direct access, since it only checks permissions and the page may well
have to be paged in from disk first.  See include/asm/uacess.h.

Same goes for PCI memory which you mustn't directly access either.  It
usually works on x86, but is not guaranteed to do so.  You have to use
readX() and writeX() macros or the memcpy_fromio() and memcpy_toio()
functions.  See include/asm/io.h.

Don't use the number tags in printk() directly, use the appropriate
KERN_xxx defines from kernel.h.  The <1> you use is KERN_ALERT and a bit
over the top for debug messages.  You can also leave them out
altogether, they get a default level then.  Not that big of a deal for a
debug driver that won't be in everyday use around the world.

All of the above should be covered in the kernel hacking guide in
Documentation/DocBook.  You can generate them there with "make psdocs",
"make pdfdocs" or "make htmldocs" in the top directory, given that you
have the appropriate tools installed.  You can also download them
already formatted somewhere, I think.

The build process is another problem.  Since the subdirectory is not
integrated into the kernel, this has to be done manually.  It is a
requirement that modules are built with the same options and include
files as the kernel they will be used with.  A separate build may range
from complete failure to subtle, hard to trace errors.

There is more than one way to solve this if you don't want to integrate
it with the kernel directly.  You can write a Makefile just as if the
driver were in fact integrated with the kernel, which allows you to then
do
	make -C $linux_src_dir modules SUBDIRS=$driver_src_dir

I haven't tried that myself, but it is reported to work.

-- 
Andreas E. Bombe <andreas.bombe@munich.netsurf.de>    DSA key 0x04880A44
--
To unsubscribe from pci mailing list please visit http://www.opencores.org/mailinglists.shtml