mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Ben Collins <bcollins@debian.org>
Cc: Arne Caspari <arnem@informatik.uni-bremen.de>,
	Adrian Bunk <bunk@stusta.de>,
	linux1394-devel@lists.sourceforge.net,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [2.6 patch] ieee1394_core.c: remove unneeded EXPORT_SYMBOL's
Date: Mon, 20 Dec 2004 20:15:17 +0000	[thread overview]
Message-ID: <1103573716.31512.10.camel@localhost.localdomain> (raw)
In-Reply-To: <20041220154638.GE457@phunnypharm.org>

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
> > driver
> 
> 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.

> into the kernel mainline. But that API is needed, none-the-less, to expose
> the internals of the system.
> 
> I'd hate to think that our "license" worries outweigh the small hacker
> community for some projects.

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).

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.

Think of it as a case of the office cleaner having not realised the pile
of paper on the floor was important, thats all.

As to the video stuff - merging that is a parallel but unrelated
question and it seems it would be benefical to all involved.

Alan


  reply	other threads:[~2004-12-20 21:21 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-20  1:53 Adrian Bunk
2004-12-20  2:10 ` Dan Dennedy
2004-12-20  2:25   ` Adrian Bunk
2004-12-20  2:42     ` Lee Revell
2004-12-20  4:27       ` Dan Dennedy
2004-12-20 22:53         ` Adrian Bunk
2004-12-20 22:58           ` Lee Revell
2004-12-20 23:02             ` Adrian Bunk
2004-12-20 23:21               ` Lee Revell
2004-12-21  0:40               ` Alan Cox
2004-12-21 17:17             ` Greg KH
2004-12-21 17:20               ` Lee Revell
2004-12-21 17:27                 ` Greg KH
2004-12-21 22:19                 ` Theodore Ts'o
2004-12-22 14:08                   ` Alan Cox
2004-12-20  9:01 ` Arne Caspari
2004-12-20 12:15   ` Arjan van de Ven
2004-12-20 13:20     ` Arne Caspari
2004-12-20 14:35       ` Alan Cox
2004-12-22  8:29       ` Arjan van de Ven
2004-12-22  8:57         ` Stefan Richter
2004-12-22 12:01           ` Christoph Hellwig
2004-12-22 12:21             ` Arne Caspari
2004-12-22 16:04             ` Stefan Richter
2004-12-20 14:39   ` Ben Collins
2004-12-20 15:15     ` Alan Cox
2004-12-20 15:46       ` Ben Collins
2004-12-20 20:15         ` Alan Cox [this message]
2004-12-21  8:33           ` Arne Caspari
2004-12-21 12:00             ` Adrian Bunk
2004-12-21 12:49               ` Arne Caspari
2004-12-21 17:15                 ` Greg KH
2004-12-21 18:51                   ` Arne Caspari
2004-12-21 18:58                     ` Greg KH
2004-12-20 17:51   ` Adrian Bunk
2004-12-20 21:05     ` Lee Revell
2004-12-20 21:49       ` girish wadhwani
2004-12-21  8:37         ` Arne Caspari
2004-12-21  9:06           ` Bernard Leach
2004-12-21 23:35         ` Pieter Palmers
2004-12-22  0:56           ` Lee Revell
2004-12-21  0:42     ` updated: " Adrian Bunk
2004-12-21  8:46       ` Arne Caspari
2004-12-21 17:13         ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1103573716.31512.10.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=arnem@informatik.uni-bremen.de \
    --cc=bcollins@debian.org \
    --cc=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome