linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott Robert Ladd <lkml@coyotegulch.com>
To: Jesper Juhl <juhl-lkml@dif.dk>
Cc: Valdis.Kletnieks@vt.edu, Borislav Petkov <petkov@uni-muenster.de>,
	Edgar Toernig <froese@gmx.de>, jmerkey <jmerkey@utah-nac.org>,
	linux-kernel@vger.kernel.org
Subject: Re: Automatic .config generation
Date: Sun, 15 May 2005 10:08:55 -0400	[thread overview]
Message-ID: <428757F7.1030700@coyotegulch.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0505151148220.2387@dragon.hyggekrogen.localhost>

Jesper Juhl wrote:
> Where's the harm in just building all the sound 
> modules - you only load one in the end anyway, and the space taken by the 
> other modules is negligible with the disk sizes of today I'd say (ok, 
> there's some extra build time involved, but that shouldn't be a big deal 
> either).

A desktop computer with a large hard drive may be the norm for kernel
developers, but it isn't (by far) the only environment where the kernel
is built. Embedded devices, small systems, older hardware, and
heterogenous networks all require a bit more finesse than a simple
"build it all and throw the mess at the hardware" approach.

The complexity of the kernel is growing, making it more difficult for
people to understand what they need and how to get it. It seems to me
that a computer can analyze itself to determine the "best" build
options. That's part of the reasoning behind my Acovea technology --
reducing complexity through smarter software.

    http://www.coyotegulch.com/products/acovea

Acovea isn't directly applicable to the kernel, but the idea of the
computer performing self-discovery is certainly valid. Once I get
another project finished, I'm going to take a more formal look at kernel
configuration, and see what might be done.

..Scott

  parent reply	other threads:[~2005-05-15 14:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-12 18:05 Automatic .config generation Scott Robert Ladd
2005-05-12 17:07 ` jmerkey
2005-05-12 18:21   ` Matthias-Christian Ott
2005-05-12 18:49     ` Steven Rostedt
2005-05-12 18:33   ` Lennart Sorensen
2005-05-12 21:17   ` Edgar Toernig
2005-05-15  7:03     ` Borislav Petkov
2005-05-15  7:42       ` Valdis.Kletnieks
2005-05-15  9:52         ` Jesper Juhl
2005-05-15 11:13           ` Valdis.Kletnieks
2005-05-16 12:50             ` Steven Rostedt
2005-05-15 14:08           ` Scott Robert Ladd [this message]
2005-05-15 13:52     ` aq
2005-09-06  9:02 Ahmad Reza Cheraghi
2005-09-06  9:12 Ahmad Reza Cheraghi
2005-09-08 20:39 Ahmad Reza Cheraghi
2005-09-08 21:13 ` Alex Riesen
2005-09-09  7:48   ` Ahmad Reza Cheraghi

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=428757F7.1030700@coyotegulch.com \
    --to=lkml@coyotegulch.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=froese@gmx.de \
    --cc=jmerkey@utah-nac.org \
    --cc=juhl-lkml@dif.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=petkov@uni-muenster.de \
    /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).