From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 10 Apr 2001 12:51:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 10 Apr 2001 12:50:37 -0400 Received: from deliverator.sgi.com ([204.94.214.10]:3892 "EHLO deliverator.sgi.com") by vger.kernel.org with ESMTP id ; Tue, 10 Apr 2001 12:49:47 -0400 From: "richard offer" Message-Id: <1010410095237.ZM1290@sgi.com> Date: Tue, 10 Apr 2001 09:52:36 -0700 In-Reply-To: Jamie Lokier "Re: build -->/usr/src/linux" (Apr 10, 6:42pm) In-Reply-To: <3AD079EA.50DA97F3@rcn.com> <20010408161620.A21660@flint.arm.linux.org.uk> <3AD0A029.C17C3EFC@rcn.com> <9aqmgo$8f6ol$1@fido.engr.sgi.com> <10104091601.ZM401478@sgi.com> <20010410160825.A20555@pcep-jamie.cern.ch> <1010410093615.ZM1231@sgi.com> <20010410184237.A20969@pcep-jamie.cern.ch> X-Signature: Automatically generated by Richards Own Mail Signer (roms) X-Home-Page: http://reality.sgi.com/offer/ X-Mailer: Z-Mail (5.0.0 30July97) To: Jamie Lokier Subject: Re: build -->/usr/src/linux Cc: linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org * $ from lk@tantalophile.demon.co.uk at "10-Apr: 6:42pm" | sed "1,$s/^/* /" * * * richard offer wrote: * > * > uname does not always provide useful information (cross compiling). Even * > * > if you're building the same ISA, you maybe in a chroot'ed environment. * > * > * > * > Can we please not assume that everybody only ever builds native... * > * * > * Nobody is assuming that. If you're hard enough to do a cross compile, * > * you can build external modules using "make KERNEL_RELEASE=2.4.2 * > * KERNEL_SOURCE=/home/jamie/cross_compiling/kernel ARCH=mips64" or * > * whatever. * > * > Applications make that assumption all the time. * > * > Yes, this is the kernel mail list, but applications use kernel services. By * > tacitly agreeing that you get the kernel headers from /lib/modules/`uname * > -r`/build/include that's what people will code into their makefiles. * * _Applications_ should not use kernel headers at all. For ioctls, they * should ship with copies of the definitions they need. That's been made * clear as crystal many times on this list, and it should be in the FAQ if * it isn't already. What if your application contains some user code and a kernel module ? Want an obvious example ? X. * * > Saying "oh, but applications should do that" isn't much of a argument, * > as there isn't a better way of working out where a set of kernel * > headers are. s/should/shouldn't/ * * -- Jamie * richard. ----------------------------------------------------------------------- Richard Offer Technical Lead, Trust Technology. "Specialization is for insects" __________________________________________http://reality.sgi.com/offer/