Re: [oc] Re: PCI Linux driver

["Miha Dolenc" <miha@iprom.si>]

Andreas,

    Thanks for your quick reply, comments and guidelines. This was my first
Linux kernel programming attempt, so I'm not that current on kernel
versions, what functions are currently used and what's supposed to be
deprecated. Maybe driver looks old, because I did it with help of an old
book ;-) for kernels 2.1 and lower. I will repair it when needed.
If you are interested in helping out, you can join pci team mailing list, so
we'll have experts on as many areas as possible. In that case, you don't
have to worry about reading PCI spec, since a lot of us did it already and
we could answer any question you might have ( at least we should be able to
;-) ).

Have fun!

Miha Dolenc

----- Original Message -----
From: "Andreas Bombe" <andreas.bombe@munich.netsurf.de>
To: <cores@opencores.org>
Cc: <pci@opencores.org>
Sent: Friday, July 27, 2001 1:18 AM
Subject: [oc] Re: PCI Linux driver


> 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 cores mailing list please visit
http://www.opencores.org/mailinglists.shtml

--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml