On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> On Monday 26 November 2007 17:15:44 Roland Dreier wrote:
> > > Except C doesn't have namespaces and this mechanism doesn't create them.
> > > So this is just complete and utter makework; as I said before, noone's
> > > going to confuse all those udp_* functions if they're not in the udp
> > > namespace.
> >
> > I don't understand why you're so opposed to organizing the kernel's
> > exported symbols in a more self-documenting way.
>
> No, I was the one who moved exports near their declarations. That's
> organised. I just don't see how this new "organization" will help: oh good,
> I won't accidentally use the udp functions any more?!?
>
> > It seems pretty
> > clear to me that having a mechanism that requires modules to make
> > explicit which (semi-)internal APIs makes reviewing easier
>
> Perhaps you've got lots of patches were people are using internal APIs they
> shouldn't?
>
Maybe the issue is "who can tell" since what is external and what is
internal is not explicitly defined?
> > , makes it
> > easier to communicate "please don't use that API" to module authors,
>
> Well, introduce an EXPORT_SYMBOL_INTERNAL(). It's a lot less code. But you'd
> still need to show that people are having trouble knowing what APIs to use.
> > and takes at least a small step towards bringing the kernel's exported
> > API under control.
>
> There is no "exported API" to bring under control.
Hmm...apparently, there are those that are struggling...
> There are symbols we
> expose for the kernel's own use which can be used by external modules at
> their own risk.
>
> > What's the real downside?
>
> No. That's the wrong question. What's the real upside?
Explicitly documenting what comprises the kernel API (external,
supported) and what comprises the kernel implementation (internal, not
supported).
>
> Let's not put code in the core because "it doesn't seem to hurt".
>
agreed.
> I'm sure you think there's a real problem, but I'm still waiting for someone
> to *show* it to me. Then we can look at solutions.
I think the benefits should include:
- forcing developers to identify their exports as part of the
implementation or as part of the kernel API
- making it easier for reviewers to identify when developers are adding
to the kernel API and thereby focusing the appropriate level of review
to the new function
- making it obvious to developers when they are binding their
implementation to a particular kernel release
> Rusty.
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
