Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263558AbTETROZ (ORCPT ); Tue, 20 May 2003 13:14:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263798AbTETROZ (ORCPT ); Tue, 20 May 2003 13:14:25 -0400 Received: from terminus.zytor.com ([63.209.29.3]:20126 "EHLO terminus.zytor.com") by vger.kernel.org with ESMTP id S263558AbTETROY (ORCPT ); Tue, 20 May 2003 13:14:24 -0400 Message-ID: <3ECA60B0.6040402@zytor.com> Date: Tue, 20 May 2003 10:06:56 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en, sv MIME-Version: 1.0 To: Chris Friesen CC: Riley Williams , David Woodhouse , "Eric W. Biederman" , linux-kernel@vger.kernel.org Subject: Re: Recent changes to sysctl.h breaks glibc References: <3ECA3535.7090608@nortelnetworks.com> In-Reply-To: <3ECA3535.7090608@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1687 Lines: 47 Chris Friesen wrote: > Riley Williams wrote: > >> First, is there anything in include/asm that is actually needed >> outside the kernel itself? There shouldn't be, and if there is, >> it needs to be moved to a header under include/linux that is >> included in the relevant include/asm file. > > It's handy for stuff like getting high res timestamps without having to > ifdef the case of building on different architechtures. Also, there are > files under include/linux which end up including asm stuff in turn. > >> The basic rule would be that external software can make free >> use of headers under include/linux but should never make any >> use whatsoever of headers under include/kernel or include/asm >> for any reason. > > > What if the include/linux files themselves make use of the asm files? > No, not acceptable. The thing is, trying to redefine the old namespaces is hopeless at this point. Hence the proposed new namespace ... would be my preference for an arch-specific subnamespace. Thus the rule is: a) files MUST NOT include files outside b) and are legacy namespaces. They should be considered to be completely different in kernel and userspace -- in effect, glibc will eventually ship with its own set of these headers. c) files should be clean for inclusion from either kernel or userspace. -hpa - 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/