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

[Lee Revell <rlrevell@joe-job.com>]

On Tue, 2004-12-21 at 00:02 +0100, Adrian Bunk wrote:
> On Mon, Dec 20, 2004 at 05:58:06PM -0500, Lee Revell wrote:
> > On Mon, 2004-12-20 at 23:53 +0100, Adrian Bunk wrote:
> > > 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:
> > > > > 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.
> > > 
> > 
> > What if the driver is under development and doesn't work yet?
> 
> For a driver developer, it shouldn't be a big problem to re-add an 
> EXPORT_SYMBOL or even to undo an #if 0 of a currently unused function.
> 

OK, fair enough.  The lack of any IEEE-1394 audio support has been a big
topic on alsa-devel and I just want to make sure we don't do anything
that would make life more difficult for vendors trying to get their
hardware supported.  Keep in mind that many vendors only have dealt with
Windows and OSX drivers, so their driver developers might be very
skilled but have not dealt with Linux before - they are used to working
with published APIs.

Anyway since the freebob project does not care about these I have no
objection to unexporting them.

Lee