lkml.org 
[lkml]   [2007]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
    On Sat, Nov 24, 2007 at 03:53:34PM +1100, Rusty Russell wrote:
    > So, you're saying that there's a problem with in-tree modules using symbols
    > they shouldn't? Can you give an example?
    >
    > > I believe that is fairly important in tree too because the
    > > kernel has become so big now that review cannot be the only
    > > enforcement mechanism for this anymore.
    >
    > If people aren't reviewing, this won't make them review. I don't think the

    With millions of LOC the primary maintainers cannot review everything.
    It's not that anybody is doing a bad job -- it is just so much code
    that explicit mechanisms are better than implicit contracts.

    > problem is that people are conniving to avoid review.

    No of course not -- it is just too much code to let everything
    be reviewed by the core subsystem maintainers. But with explicit
    marking of internal symbols they would need to look at it because
    the relationship will be clearly spelled out in the code.

    > > Several distributions have policies that require to
    > > keep the changes to these exported interfaces minimal and that
    > > is very hard with thousands of exported symbol. With name spaces
    > > the number of truly publicly exported symbols will hopefully
    > > shrink to a much smaller, more manageable set.
    >
    > *This* makes sense. But it's not clear that the burden should be placed on
    > kernel coders. You can create a list yourself. How do I tell the difference
    > between "truly publicly exported" symbols and others?

    Out of tree solutions generally do not scale. Nobody else can
    keep up with 2+ Million changes each merge window.

    >
    > If a symbol has more than one in-tree user, it's hard to argue against an

    There are still classes of drivers. e.g. for the SCSI example: SD,SG,SR etc.
    are more internal while low level drivers like aic7xxx are clearly external
    drivers.

    > out-of-tree module using the symbol, unless you're arguing against *all*
    > out-of-tree modules.

    No, actually namespaces kind of help out of tree modules. Once they only
    use interfaces that are really generic driver interfaces and fairly stable
    their authors will have much less pain forward porting to newer kernel
    version. But currently the authors cannot even know what is an instable
    internal interface and what is a generic relatively stable driver level
    interface. Namespaces are a mechanism to make this all explicit.

    -Andi
    -
    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: 2007-11-24 13:43    [W:6.551 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site