Re: [2.6 patch] ieee1394_core.c: remove unneeded EXPORT_SYMBOL's

[Adrian Bunk <bunk@stusta.de>]

On Sun, Dec 19, 2004 at 11:27:50PM -0500, Dan Dennedy wrote:
> On Sun, 2004-12-19 at 21:42 -0500, Lee Revell wrote:
> > On Mon, 2004-12-20 at 03:25 +0100, Adrian Bunk wrote:
> > > On Sun, Dec 19, 2004 at 09:10:10PM -0500, Dan Dennedy wrote:
> > > > On Mon, 2004-12-20 at 02:53 +0100, Adrian Bunk wrote:
> > > > > The patch below removes 41 unneeded EXPORT_SYMBOL's.
> > > > 
> > > > Unneeded according to whom, just you? These functions are part of an
> > > > API. How do I know someone is not using these in a custom ieee1394
> > > > kernel module in some industrial or research setting or something new
> > > > under development to be contributed to linux1394 project?
> > > 
> > > If someone uses some of them in code to be contributed to the linux1394 
> > > project, re-adding the EXPORT_SYMBOL's in question is trivial.
> > > 
> > > If someone uses some of them in a custom setting, re-adding them is 
> > > trivial, too.
> > > 
> > > If the only user of one or more of these EXPORT_SYMBOL's was a non-free 
> > > module, it's kernel policy that the EXPORT_SYMBOL's in question have to 
> > > be removed.
> > 
> > What do you tell a vendor who wants to write a driver for their device?
> > "OK, about half the functions you need are in the kernel, the other half
> > you have to port from this old kernel because we removed them.  Maybe we
> > will put them back if we really like your driver"?
> 
> While I think some of Adrian's points are valid, I am exercising caution
> because I am a new maintainer for linux1394 (although not new to the
> project in general). This is an interface version management issue IMHO.
> Adrian is not suggesting to remove the functions yet, but it is
> effectively the same thing to an outsider. A vendor or services provider
> would have to modify kernel source to let their driver work again, which
> is not technically challenging to kernel hackers, but frustrating
> situation to be in as a vendor or customer. It creates a mess in
> support, distribution, deployment, etc.

The solution is simple:
The vendor or services provider submits his driver for inclusion into 
the kernel which is the best solution for everyone.

> Do I have specific examples where removing these symbols would cause
> breakage? No, but I do provide contracted services based on linux1394, I
> know of a guy developing a v4l2 driver that likely needs some of these,
> and some have been considering new alsa and v4l2 drivers that could use
> these. Besides, there is a lot in the wild we do not know about - free
> or non-free. It would suck to say you can not use these custom or new
> drivers on your distro's kernel and you need to wait for an upgrade if
> not willing to customize and compile.

You didn't explicitely say whether the results of the contracted 
services you offer are free or non-free.

If the result is free, inclusion into the kernel is simply the optimal 
solution.

If the result is non-free, it;s kernel policy that there are no 
EXPORT_SYMBOL's specifically for non-free modules (and that a free 
module might some day use them is not a reason).

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed