On Thursday 24 November 2005 07:56, Roman Zippel wrote:
> Hi,
>
> On Mon, 21 Nov 2005, Rob Landley wrote:
> > Add "make miniconfig", plus documentation, plus the script that creates a
> > minimal mini.config from a normal .config file.
>
> The difference between miniconfig and allnoconfig is IMO too small to be
> really worth it right now.
I disagree, fairly strongly. The technical difference may be small, but the
conceptual difference is huge.
>From a user interface perspective, make miniconfig and make allnoconfig are
two very different things. Make allnoconfig is supposed to make a config
where you answer "no" to all the questions. The name is fairly intuitive.
>From a user interface perspective, overloading it with miniconfig
functionality kind of sucks. When a user is supplying a miniconfig, what
they're trying to accomplish is _different_ than what allnoconfig has
traditionally done. The fact that the same infrastructure can do both is an
implementation detail. Even if there were _no_ other changes, I'd urge
adding it as a synonym that takes a different filename.
That's apart from the fact that allnoconfig doesn't return an error when you
try to set nonexistent symbols (which makes sense for allnoconfig; any
warnings there really aren't something a user is normally interested in). Or
that the pointless information it dumps to stdout buries any useful
information going to stderr (again, for allnoconfig the warnings are only
really of interest to developers).
Or the _big_ change, that miniconfig should _die_ if it can't find the
mini.config file (because it has nothing to do), yet allnoconfig happily
completes successfully. That is the right thing for allnoconfig to do, and
exactly the _wrong_ thing for miniconfig to do. (It's especially problematic
when specifying an alternate location for the file: if you typo it, there's
no way to tell except by inspecting the verbose .config, or else finding out
after you build that you built garbage.)
If your objection is to the size of the patch, I can make the patch bigger.
Seems kind of counterproductive and something I was actually trying to
_avoid_ doing. (I didn't even rename KCONFIG_ALLSYMS, despite having to look
the darn name up every single time I use it, because I was trying to keep the
footprint down.) But if the change isn't _big_ enough...
By the way, various other bits of the kernel build don't give me an error
return when something goes wrong. (For example, if a config
CONFIG_INITRAMFS_SOURCE that doesn't exist, the build happily completes with
an empty initramfs. I have a to-do item to patch that, but it's a bit down
on the list. (Also, note that the fact you can specify things like
CONFIG_INITRAMFS_SOURCE and CONFIG_LOG_BUF_SHIFT is obvious when talking
about mini.config but an "aha" moment when talking about allno.config. I
like things that need fewer "aha" moments to understand.)
> If we go that path, this functionality should be integrated properly.
I've actually been using condensed configuration subsets since March 16
(according to my build log http://www.landley.net/code/firmware/notes.html).
I.E. I was already doing this eight months ago. This functionality was
already of use to me long before it came up on the list, and I think it would
be something of larger utility if it were properly documented.
Which is why my first step was documenting the new way of doing things when
2.6.15-rc1 broke something that had worked for me consistently ever since
2.6.10. (Of course I could have also documented how to work around the
breakage by now sticking the symbols at the _start_ of the file. But that
wouldn't have been polite.)
The new "recommended" mechanism for doing what I wanted was not only entirely
undocumented (and documenting it is where I noticed that the user interface
sucked), but also the fact it was of use to me seemed largely accidental. It
was a side effect of a change that added variants like "allrandom.config".
Keep in mind that I was moved to do this work because the way I'd _been_
performing this function for 8 months got broken by random outside
developments. So now it's a side effect of a _new_ set of things. Wheee.
I'm all for future improvements. My makemini.sh shell script sucks deeply,
I'll be the first to acknowledge that. But what I've proposed is a user
interface I can document, one that meets my needs, and one I expect will be
useful to others who are not deeply familiar with the configuration
internals.
I could always treat the whole "make config" as something to be worked around
with a wrapper script to give it a user interface based on the task humans
are trying to do rather than how the plumbing happens to be laid out. (The
logical name for the new script would of course be "./configure".) But I'd
rather work _with_ the kernel than against it, and make it easier for others
to do what I find useful.
I really do think this is an improvement from a user interface perspective,
and the smallest change I could come up with from a technical perspective to
meet my goals.
> What I have in mind is to create a new config file with a bit different
> format,
What's wrong with the format of mini.config?
> which is only read by kconfig.
So it would be different from the format of the busybox .config file, the
uClibc .config file, or anybody else out there who's adopted the kernel's
format over the past decade-plus?
> This one can also have a switch
> "only save the minimum". The important part is that if this file exists,
> all kconfig front ends will use it and keep it properly uptodate.
I'd be quite happy if mini.config could be written directly by kconfig. (It
would do a much faster job than my dumb shrinker script. I repeat: my
shrinker script is crap.)
However, you seem to be forgetting that .config is read by the kernel build
infrastructure. The tools are generating what _used_ to be a human editable
file.
> 'make miniconfig' would then simply convert the current config to a
> minimized version.
So the new format would _not_ be a minimized version. Uh-huh. So there's
still two versions...
So how would you make use of this new minimized version, then? If somebody
file attached one in a linux kernel message and a developer wanted to debug
their issue?
> One problem I see with this how kconfig should behave,
> when it's thrown into a new kernel release.
With mini.config, it's actually fairly portable between versions. (As I said,
it's worked for me since 2.6.10.) It specifies the interesting symbols (the
ones I'd specify in menuconfig), and then the dependencies should resolve
themselves (which kconfig does right now). New versions seldom drop or
rename interesting features (if they did, make oldconfig wouldn't be of much
use). The simple fact is, mini.config doesn't specify anything particularly
version specific. The dependencies are in the stuff it _doesn't_ mention, it
just says "I want this set of features" and any kernel newer than the one it
was created on should have them unless they got obsoleted (which requires
human intervention to fix anyway).
In fact, my old uml-config file from a few versions back still works in 2.6.15
just fine. It works as a mini.config, or it works if I append the .config
generated by "make allnoconfig" file to _it_ rather than appending it to
the .config, before running "make oldconfig" to clean it up. That change was
only required because some random code change the kconfig developers made
broke it, because the behavior I was counting on was never intentional.
I'd like the behavior I'm relying on to be clearly intentional. Not an
accident that works until the next time the kconfig code is touched.
> Setting everything else to 'n'
> is one possibility, but sometimes such options as CONFIG_SWAP are added,
> which one certainly wants enabled. Using the defaults would be a
> possibility, but they are currently massively abused (and I'll probably
> soon start a cleanup of them).
The miniconfigs I've been using (and the ones this patch uses) are based on
allnoconfig. This means that any features I don't specify, I probably don't
want unless they're actually required. That can be version independent.
That's much less likely to introduce strange new things like devfs
automounting
> > 1) Documentation.
>
> This is of course always nice, but it would be even better, if it also
> included information about the other config targets, even it's mostly a
> place holder.
Why? The target audience for miniconfig is people who want to save the work
they did in menuconfig (and yes, configuring a kernel is work) without tons
of extraneous version-dependent crap. So they can give it to someone else
who can see what options were important to them without having to pull up a
GUI to interperet the data for them. And so they can bring it forward to new
versions.
And no, taking your 2.6.12 .config and running "make oldconfig" against it is
_not_ a solution because any new symbols are set to the defaults out of
defconfig, and a lot of those defaults are switched on. So if you just run
oldconfig (or make menuconfig and exit without dredging through each sub-menu
looking for symbols marked "new", which isn't 100% reliable) you wind up with
new extraneous crap accumulating in your config file with each version.
And no, you can't go `yes "n" | make oldconfig` because that goes into an
endless loop when oldconfig prompts you for a number. Been there, done
that...
I don't personally _care_ about the other config targets. They don't do what
I'm trying to do here. Conceptually, mini.config files are different
from .config files because mini.config files are human editable and version
independent. Conventional .config files are neither. I'm trying to document
a useful technique which, to me, has _nothing_ to do with the rest of the
plumbing changes you made. It's a technique I was using long before the
latest batch of changes, and your changes made it easier to promote it to a
fully supported feature but it really doesn't seem to me that this technique
was not what you had in mind when you made your changes.
I realise that you added allyes.config, allrandom.config, allmod.config, and
so on. But allnoconfig was the _only_ sane base for what I was trying to do.
I did actually think this through, many moons ago.
defconfig changes from version to version. New drivers show up for things you
don't have. Stuff you were using could go away simply because the defaults
changed. It's close to useless.
Allyesconfig and allmodconfig are not a sane base. New drivers show up all
the time so switching off everything you don't need is A) insanely verbose,
B) not portable to new versions with new drivers. And new stuff can show up
that breaks you: devfs automounting,
What's allrandom.config even for? Maybe it's potentially a developer only
thing to ensure that an allrandconfig kernel has the minimal set of options
to potentially boot on your test hardware. (Except that make allrandconfig
is used almost exclusively to test _building_, not booting, because testing
that hardware you don't have isn't found by the probes generally is not all
that interesting of a test (and one you could pretty much do with
allyesconfig or allmodconfig if you cared). But maybe I could see the Linux
Test Project guys potentially spending spare cycles on this.) But again,
completely different group of people than the audience for make miniconfig.
> bye, Roman
I have something working now, something a lot of thought went into. I really
do think it's a good idea...
Rob
--
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
