From: Keith Owens <kaos@ocs.com.au>
To: linux-hotplug@vger.kernel.org
Subject: Re: Automatic download and installation of drivers.
Date: Wed, 31 Oct 2001 12:36:05 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-100453180102602@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-100319421829170@msgid-missing>
On Mon, 29 Oct 2001 13:53:40 -0800,
Greg KH <greg@kroah.com> wrote:
>On Thu, Oct 18, 2001 at 01:19:47AM +0100, Stamatis Mitrofanis wrote:
>> I agree that a C compiler is a nice thing to have, but no one must be
>> forced to have it (say, end users). If it becomes a "base package",
>> every computer must have it installed and then people will start using
>> it when it's not necessary (huge mess). The best thing to do here is to
>> install the right version of gcc on demand (just as we do for drivers).
>
>And what version of gcc would you install? Different versions for
>different vendor kernels and even releases :)
I have decided to add CONFIG_KBUILD_GCC_VERSION to kbuild 2.5, it
records the values of gcc -b and -V used to build the kernel. The
string is automatically generated and added to the .config, _every_
source file will implicitly depend on that config variable so changing
the compiler will force a complete recompile.
Building the kernel and modules from a mixture of compilers is not a
supported operation.
This is almost true in kbuild 2.5 already. If you compile with 'gcc'
then recompile with 'kgcc' or switch from 'gcc' to 'gcc -V 3.0.1',
everything gets rebuilt because the compiler name and flags are part of
the saved command, any change in a command forces a recompile of the
affected objects. Adding the CONFIG_ variable will document which
compiler was used and catches the pathological case where 'gcc' is used
but it points to different compilers on different days.
Version information for other build utilities will be added as required.
>But I don't keep my kernels in /usr/src/linux, and neither do most
>people. And vendor kernels include a number of different .config files,
>all of them placed in a different file within the .src.rpm. Work with
>the LSB if you want to push for this kind of standardization.
Or the kbuild maintainer ;). LSB does not document down to this level
of detail so I am standardizing where .config and other files go in
2.5. /lib/modules/`uname -r`/{.config,System.map,trees}. kbuild 2.5
is not restricted to a single source tree so the single build symlink
is useless in 2.5, instead the 'trees' file defines the source tree(s)
and the object tree.
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2001-10-31 12:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-16 0:02 Automatic download and installation of drivers Stamatis Mitrofanis
2001-10-16 5:29 ` Greg KH
2001-10-16 7:35 ` David Brownell
2001-10-16 7:58 ` Tim Jansen
2001-10-16 11:38 ` Keith Owens
2001-10-16 16:52 ` Greg KH
2001-10-16 18:44 ` Tim Jansen
2001-10-16 18:58 ` Tim Jansen
2001-10-16 19:19 ` Greg KH
2001-10-17 2:01 ` David Brownell
2001-10-17 2:03 ` David Brownell
2001-10-17 18:47 ` Tim Jansen
2001-10-17 19:24 ` David Brownell
2001-10-17 23:31 ` Tim Jansen
2001-10-17 23:32 ` Greg KH
2001-10-18 0:07 ` Dmitri
2001-10-18 0:19 ` Stamatis Mitrofanis
2001-10-18 0:47 ` Tim Jansen
2001-10-18 2:17 ` Keith Owens
2001-10-18 2:35 ` Dmitri
2001-10-29 21:53 ` Greg KH
2001-10-30 8:26 ` Tim Jansen
2001-10-30 17:21 ` Greg KH
2001-10-30 21:24 ` Tim Jansen
2001-10-30 21:51 ` Dmitri
2001-10-31 12:36 ` Keith Owens [this message]
2001-10-31 20:49 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-hotplug-100453180102602@msgid-missing \
--to=kaos@ocs.com.au \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).