Greg KH wrote:
On Wed, Jan 18, 2012 at 04:49:27PM +0100, Martin Burnicki wrote:
Hi folks,
I'm maintaining the driver software for the PCI cards manufactured
by our company, Meinberg Funkuhren in Germany. Basically our Linux
driver supports all our PCI cards on all Linux kernels 2.6.x and
3.x. The PCI cards are e.g. GPS receivers, radio clocks, or IRIG
time code receivers.
Nice, any reason why these drivers aren't in the main kernel.org tree?
Yes, you wouldn't like the coding style of our driver ;-)
Seriously, I have discussed this with some Linux guys before, and also
with some folks from *BSD who also wanted to pick up the driver into
their *BSD source trees.
The disadvantages of this approach were:
- If someone wanted to use a new type of PCI card then he was forced to
upgrade the kernel to get support for it. We have quite a number of
customers who want to stick with a specific Linux distribution version
(and thus kernel version) for some reason, so they wouldn't be able to
use a newer PCI card model unless they backport a newer driver to an
older kernel. E.g. we have a number of customers who still run some old
RHEL versions with kernels around 2.6.16 or so, but they are using
current PCI card models.
- Sometimes it happens that new features are implemented in the firmware
of the PCI cards, often even on request of a customer. To benefit from
such new features the appropriate changes needed to be made in the
driver code, and again this would require some backporting if the user
is not willing to upgrade the kernel.
- The driver code would have to be reformatted for Linux to comply with
the Linux coding style, for FreeBSD to comply with the FreeBSD coding
style, etc.
Our cards are often used as reference time source for ntpd, but also for
measurement applications which access the cards directly. In any way,
the cards provide usually quite a number of configuration parameters
which can be or need to be set up properly, depending on the requirements.
API calls required for these cards include reading high resolution,high
accurate timestamps from the card, but also lots of configuration stuff,
e.g. reading which IRIG code formats are supported by a given IRIG
receiver card, and configuring the selected IRIG code to be decoded by
the card. The huge amount of API calls is very specific to our cards.
Actually our driver code is divided into some pieces of OS-specific code
and a huge piece of code which is shared for all supported operating
systems, including Linux, Windows, FreeBSD, NetBSD, Novell Netware, DOS,
formerly OS/2, and even by the firmware for the microcontrollers on the
PCI devices.
There is one driver package for Linux, which can be used with all 2.6.x
and 3.x kernels, one package for FreeBSD, a single driver for all
Windows versions from WinNT up to Win7 and Server 2008. All these
drivers share a lot of source code, and in fact the API calls available
to applications are source code compatible across all supported
operating systems. We have had quite a number of customers who started
to use our cards under Windows, and then switched to Linux, and didn't
have to change the way API calls for our PCI cards are used by their
application.
Since many years our Linux driver is available as source code on our
download page:
http://www.meinberg.de/english/sw/#linux
I must admit that the driver on this page is a little bit outdated.
However, we are currently preparing a new release:
http://www.meinberg.de/download/drivers/mbgtools-lx-dev-2011-12-19.tar.gz
There's also a corresponding driver version for FreeBSD, the first
release of which will be available with the next version of the Linux
driver:
http://www.meinberg.de/download/drivers/mbgtools-fbsd-dev-2011-12-21.tar.gz
If you look into both archives you'll see that the user space tools and
mostly all the stuff below the mbglib directory is shared by both driver
packages.
For example, there is one common source code module which implements the
basic functions usually required by kernel drivers, e.g.:
- check if a particular device is supported
- start the device and detect the features it provides, which depend on
the type of card but may also depend on the firmware version actually
installed on the card
- provide different low level functions required to access cards
depending on the PCI interface chip assembled on the detected card
In addition, there is an OS-specific skeleton driver which calls those
routines if e.g. the kernel calls the probe or ioctl routine for a given
device.
So the advantages of our approach to maintain the drivers out of the
Linux or *BSD source trees are:
- we can implement new features and support new card types by making
changes *once* in the source code, and the new feature is available
immediately for all supported operating systems.
- it provides most possible flexibility for the folks who use our PCI
cards since they can use our latest driver for the newest cards even
with older distributions/kernels. Just unpack the archive, type
make && make install
and that's it.
I'd like to point out explicitely that our approach is *not* because we
want to keep some stuff as secret. Everything is available as source
code, and you can grab a copy of the code and merge it into the kernel
tree, if you want. However, maintaining the driver code would be much
harder then since for a new feature the Linux tree needed to be updated,
*BSD trees needed to be updated, and we'd need to maintain our local
code base anyway to support those operating systems which are not open
source.
BTW, we are currently also working on a GUI application which is based
on wxWidgets and can be used to view and modify configuration parameters
on our different PCI card types under different operating systems. This
project also shares much of the common code, so once more it is easier
to provide common driver packages than having a specific driver in the
kernel only.
Sorry for the lengthy reply, but I've tried to make our point as clear
as possible, and hope you understand and accept the reasoning.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
