Re: [2.6 patch] ieee1394_core.c: remove unneeded EXPORT_SYMBOL's
From: Arne Caspari
Date: Tue Dec 21 2004 - 03:39:12 EST
Alan Cox wrote:
On Llu, 2004-12-20 at 15:46, Ben Collins wrote:
You might as well remove the ifdef if you do that since vendors will
have to guess what the right answer is an will probably uniformly say
"Y". At that point its basically a non-option. Far better to submit the
You are missing the point though. Lots of these are part of our API, and
I think you missed my point. Any vendor faced with that Config option
will say Y so almost every tree will always have it - so why ask as
opposed to keeping the status quo.
My concerns with this option is actually that some mainstream
distribution will say "N" here accidentally. So every customer with this
distribution will call us and require intense support. If Linux will
cause intense support, it will just not be supported at all because
Windows support is almost zero in this regard and we make almost zero
profits with Linux sales - and 99.99 % of our income with Windows sales.
Sure but if Adrian was trying to just tidy licensing issues he'd submit
a switch to EXPORT_SYMBOL_GPL. (Admittedly for anything as closely tied
as the innards of the ieee1394 layer its probably implied anyway).
I do not see the licensing issue of a stable kernel API where venders
can rely on. Our driver is GPL so there should no be a licensing issue.
The reason why I have not submitted this driver is as follows:
If I submit a driver and there is a firmware change in our device that
breaks compatibility to older drivers ( as there once was ), customers
which get the new devices will have a driver that is not working. So
each customer asks us for support and we need to guide him to replace
the kernel driver with the new one. This situation will remain until
mainstream distributions update their kernel.
In the current situation we just have a website which says that you have
to get the driver from sourceforge and compile it yourself. This works
rather good: Customers that bought a device automatically got the right
driver. And if I need to make some changes in the driver ( ie. fix bugs
or add functionality ), I do not need to wait until the patches go into
mainstream distributions ( you can not wait for that ) but just update
the SF site and let the customer go through the same steps he already
had gone through in the beginning.
It is all about avoiding ( expensive ) support. I can not stress this
point enough: If supporting Linux becomes a cost factor it will just not
be supported. There is virtually no profit for us in this market.
There are two conflicting goals here - to have clean complete API's and
to stamp out the large number of unused, historic and at times bogus
exports. If these API's are needed and used then they should stay just
as some others elsewhere in the kernel have.
On Windows I can rely on a stable kernel API for many years now. We have
single drivers that work on the WindowsXP of today and also work on
Windows 2000 which is almost 5 years old. They would most likely even
work on Windows98 if we would support that platform. Windows circumvents
the symbol export problem by using their IO Request Blocks etc. which
makes things more complicated but at least stable.
Linux does not have such a model. So in my eyes, special care has to be
taken to generate an API that is valid today and will remain valid for
some years. Vendors need to be able to rely on a stable API.
I would take it like in a library: The API should not change between
minor versions - likewise it should be stable in the kernel among all
2.6.x versions. If it changes to version 2.7.x or 2.8.x it would be OK
since we could release a driver for a 2.8.x tree then.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/