lkml.org 
[lkml]   [2003]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux GPL and binary module exception clause?
    On Wed, Dec 03, 2003 at 04:23:33PM -0800, Linus Torvalds wrote:

    > Side note: historically, the Linux kernel module interfaces were really
    > quite weak, and only exported a few tens of entry-points, and really
    > mostly effectively only allowed character and block device drivers with
    > standard interfaces, and loadable filesystems.
    >
    > So historically, the fact that you could load a module using nothing but
    > these standard interfaces tended to be a much stronger argument for not
    > being very tightly coupled with the kernel.
    >
    > That has changed, and the kernel module interfaces we have today are MUCH
    > more extensive than they were back in '95 or so. These days modules are
    > used for pretty much everything, including stuff that is very much
    > "internal kernel" stuff and as a result the kind of historic "implied
    > barrier" part of modules really has weakened, and as a result there is not
    > avery strong argument for being an independent work from just the fact
    > that you're a module.

    FWIW, it would be very nice if somebody did hard and messy work and
    produced lists of in-tree modules using given symbols. Ideally - automated
    that, but that won't be easy to do (quite a few are used only via inlined
    wrappers and in some cases - under an ifdef; many arch-specific exports
    are of that sort).

    Aside of "hey, nothing uses that at all" and "only core uses it"
    we'd get a bunch of "hmm, we really should've exported higher-level function
    instead" and "WTF does that lone driver use this function?". I'd played
    with that for fs/* exports and so far results look interesting. I'm using
    grep, but that's pretty much hopeless - we have literally thousands of
    exported symbols and any manual approach will break on that.

    Some approximation might be obtained by building all modules and
    doing nm on them, with manual work for non-obvious cases. I've done that
    on x86 (allmodconf + enabling whatever could be enabled, even if broken).
    Statistics is interesting, to put it mildly.

    First of all, there are ~3600 symbols used by some in-tree drivers.
    ~600 of them are have 10 users or more. ~2000 have only one or two users.
    And we have ~7500 EXPORT_... in the tree. Now, that number is inflated by
    duplicates between architectures (and other stats are deflated by incomplete
    coverage). And yes, there are things that have every reason to be exported,
    but only a few modules care to use them.

    However, it certainly looks like a large fraction of export list
    should go away. Moreover, we probably should introduce
    EXPORT_FOR(symbol, module list)
    and use it for stuff like jbd poking very deep in buffer.c guts - deeper
    than anybody else. Ditto for ipv6 / ipv4 interaction - they really have
    a special relationship and it makes no sense whatsoever to treat everything
    in TCPv4 guts that happens to be shared with TCPv6 as public export. There's
    a lot of cases like that and I suspect that they cover ~50-60% of the in-tree
    imports.

    Real interface is somewhere around 400-500 symbols and it can be
    split into several more or less compact parts. Having more than an order
    of magnitude more than that, and having it as a big pile... Not a good
    thing(tm), IMO.
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:59    [W:0.025 / U:1.636 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site