[JOB] PCI device driver
xorp at 020602005a5b40404e4440475758417a.nosense.org
Wed Jul 6 14:30:43 CST 2005
On 06 Jul 2005 22:45:33 +0930
Phil Nitschke <phil at avalon.com.au> wrote:
> Hi all,
> In brief: I'm looking to employ someone to help design, code and set
> to work a proprietary PCI device driver for the Linux kernel.
> What we need is a device driver to be written for the 2.6.x kernel
> which can enable us to communicate with the registers, FIFOs and
> memory on the FPGA, via the PCI bus. The PCI device driver would need
> - take advantage of sysfs
According to the following LKML thread, you probably won't be able to
meet this requirement unfortunately :
"Please open sysfs symbols to proprietary modules"
I also suggest having a read of the following to commentaries about the
technical benefits of open source drivers. It was a rebuttle to a
Solaris developer who didn't necessarily understand the benefits of
Linux (probably no surprise :-) ), and why the best device drivers are
open source ones.
> - be up-to-date with kernel APIs/Interfaces
> - be stable, reliable, robust and manage resources well
> - employ efficient error handling, reporting and recovery
> - be SMP-safe when handling interrupts and lock synchronisation
> For someone who has done this work before, I do not think it would
> take long, because the interface to the FPGA is not too complex.
> Avalon would need to retain all rights to the driver developed for us;
> there would be no opportunity to make this driver open-source, because
> it is tied inextricably to the FPGA source.
That's disappointing. It would be better to design this device so that
all the "secret sauce" was contained in the FPGA code, and then an open
source device driver could merely provide an "instructional" OS
interface to it. The open source device driver would then not expose any
of your proprietary knowledge or techniques. You'd then get the
technical benefits of an open source device driver that Greg has
described in the above articles, as well as not have any or as many
restrictions such as the sysfs one above. It also makes the device
driver portable to other CPUs, because, hey, you may switch from a PPC
to an x86 in the future, just like Apple are.
Another advantage of putting all the smarts on the card is that it would
make writing a device driver for another OS if you needed to (say
Windows) would be a lot easier, quicker, and require less testing to be
confident of the reliablity of the device on the other OS and the device
Note that you don't have to open source the FPGA code, or embed the
FPGA, reverse-engineerable binary code within a .h file as a
pre-intialised byte array to be loaded into the FPGA by the module. It
is possible for modules to load binary blobs aka your FPGA code from
userspace / user specified files. Have a look at the bttv-cards.c file
in drivers/media/video (search for "firmware") for an example of an open
source module that does this sort of thing.
The Internet's nature is peer to peer.
More information about the linuxsa