Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

Adrian Bunk
2007-11-27T19:00:24Z

On Tue, Nov 27, 2007 at 11:45:37AM -0600, Tom Tucker wrote:
>
> On Tue, 2007-11-27 at 18:15 +0100, Adrian Bunk wrote:
> > On Mon, Nov 26, 2007 at 11:35:42PM -0600, Tom Tucker wrote:
> > > On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> > >...
> > > > 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).
> > >...
> >
> > There is not, never was, and never will be, any supported external API
> > of the kernel.
>
> Philosophically I understand what you're saying, but in practical terms
> there is the issue of managing core API like kmalloc. Although kmalloc
> _could_ change, doing so would be extremely painful. In fact anyone who
> proposed such a change would have to have a profoundly powerful argument
> as to why it was necessary.

The latter should at least in theory be required for all changes no
matter how core they are...

> I think this patchset is an attempt to make it easier to identify and
> review these kinds of interfaces.

As long as the submitter fixes all in-kernel users these interfaces are
not handled differently from interfaces with fewer users.

And I remember at least one commit that changed > 1000 files because it
changed a frequently used driver API. [1]

cu
Adrian

[1] commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed