| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1196185537.24469.21.camel@trinity.ogc.int> Date: Tue, 27 Nov 2007 11:45:37 -0600 From: Tom Tucker <tom@...ngridcomputing.com> To: Adrian Bunk <bunk@...nel.org> Cc: Rusty Russell <rusty@...tcorp.com.au>, Roland Dreier <rdreier@...co.com>, Andi Kleen <ak@...e.de>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, sam@...nborg.org Subject: Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro. 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. I think this patchset is an attempt to make it easier to identify and review these kinds of interfaces. > > cu > Adrian > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists