Re: [2.6 patch] drivers/ieee1394/: schedule unused EXPORT_SYMBOL'sfor removal

From: Stefan Richter
Date: Sat Jul 09 2005 - 14:46:31 EST


Adrian Bunk wrote:
> On Sat, Jul 09, 2005 at 03:50:35AM -0400, Ben Collins wrote:
>> Can we, instead of removing these, wrap then in a "Export full API" config
>> option? I've already got several reports from external projects that are
>
> This will end in all distributions having this option enabled resulting
> in no change compared to todays status quo.

I disagree. Distributors, especially those oriented towards private/
SOHO/ big commercial customers, don't need to care much for classroom
projects or the hacker next door. Distributors will not enable this
option once it defaults to off in mainline. This config option is
ultimately *no* solution for commercial support of external drivers,
regardless whether they are free software or unfree. The patch does not
attempt to establish a warranted managed API.

>> using most of these exported symbols, and I'd hate to make it harder on
>> them to use our drivers (for internal projects or otherwise).
>
> What are these external projects?

There are countless FireWire related projects, especially in academia.
For example, FireWire seems to be a hit in robotics. We at
linux1394-devel may not even hear about what they are doing in
particular but we do get feedback, bugfixes, and improvements from them.
For them, Linux' IEEE 1394 stack may be only one choice out of several,
including stacks in the big desktop operating systems or in various
embedded OSs. So in my personal opinion, it is in best interest for
Linux' 1394 stack if we can keep these people motivated to stick with
Linux.

> Is they are internal projects, re-adding the EXPORT_SYMBOL's should be
> trivial for them.

We make it even more trivial by providing a compile option for that. The
cost is minimal.
--
Stefan Richter
-=====-=-=-= -=== -=--=
http://arcgraph.de/sr/

-
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/