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

From: Alan Cox (alan_at_lxorguk.ukuu.org.uk)
Date: 12/20/04

  • Next message: Jan Engelhardt: "Basic UB q" 
    To: Ben Collins <bcollins@debian.org>
Date:	Mon, 20 Dec 2004 20:15:17 +0000

    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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Jan Engelhardt: "Basic UB q"

    Relevant Pages

    • Re: thoughts on kernel security issues
      ... On Iau, 2005-01-13 at 21:03, Linus Torvalds wrote: ... > be for kernel developers only or at least people who won't take ... > is whoring itself for security firms and vendors. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: thoughts on kernel security issues
      ... >> be for kernel developers only or at least people who won't take ... >> is whoring itself for security firms and vendors. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [OT] Who has record no. of DriveReady SeekComplete DataRequest errors?
      ... >> I could easily imagine some vendors not setting the field, ... >> the patch isn't the culprit after all. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: My thoughts on the "new development model"
      ... > Part of the reasoning behind the new development model is that if you ... > want a stable kernel, there are many vendors who will give you one. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
      ... > So if kexec could actually get a reserved system call number that ... I have no problem with that - it's a major feature, vendors will, I assume, ... ship it so it's worth blowing the four bytes to pin the ABI down for ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)