From: Julian Scheid <julian@sektor37.de>
To: jdike@karaya.com
Cc: user-mode-linux-devel@lists.sourceforge.net
Subject: [uml-devel] Default kernel configuration on 2.6.x
Date: Tue, 12 Oct 2004 00:22:36 +0200 [thread overview]
Message-ID: <416B07AC.3030308@sektor37.de> (raw)
[-- Attachment #1: Type: text/plain, Size: 2941 bytes --]
This is a follow-up to a private message I sent to Jeff in which I
complained about the UML Howto being incorrect in saying that "[t]he
[configuration] defaults will give you a useful kernel" since I was
using an unmodified configuration and ended up with a kernel missing all
the virtual drivers.
In the meantime I did some further research and it turns out that
actually, the Howto isn't wrong - the default configuration included in
the patches is perfectly correct and gives a useful kernel.
Instead, a well-meant feature in the 2.6 build process (IIRC present in
2.5 too) has been the cause of my difficulties: make *config tries to
locate default settings by looking for the following files in order:
> const char *conf_confnames[] = {
> ".config",
> "/lib/modules/$UNAME_RELEASE/.config",
> "/etc/kernel-config",
> "/boot/config-$UNAME_RELEASE",
> conf_defname,
> NULL,
> };
(taken from linux-2.6.8.1/scripts/kconfig/confdata.c)
In other words, if a file describing the current host kernel's
configuration is present on the host (the one under /boot is on my
Debian box) then make config in a fresh or mrproper'ed guest tree will
use the host configuration instead of the defaults supplied by the UML
patch. This is true regardless of which kernel version is running on the
host.
While this is useful under normal circumstances where you usually want
to continue using your current settings, it seems very unhelpful in the
case of a UML guest kernel since the guest kernel configuration and the
host kernel configuration are targeted at two different platforms and
thus don't have much in common, except perhaps for the choice of
filesystems if you want the guest to access your host's storage devices.
It should be noted that since the host kernel is usually not a
UML-patched kernel and therefore none of the UML-specific options are
given in the host configuration file, the consequence of the current
behaviour is that all UML-specific options default to off if one of the
listed files is present on your host.
This is especially fatal because without a virtual character device
driver, stdio initialization will fail silently or with an unhelpful
error message ("sleeping process got unexpected signal 11"), leaving
unsuspecting users like me completely puzzled.
Therefore I think it would make sense to have the UML patches for the
affected kernel versions remove the second through fourth element from
conf_confnames (as shown above) so that the build will immediately fall
back to arch/um/defconfig if .config isn't found, always ignoring status
quo configuration files on the host. A corresponding patch for 2.6.8.1
is attached.
Perhaps a note should be added somewhere pointing out the non-standard
behavior to avoid confusing seasoned kernel recompilers, but I'm not
sure where to put it. I'll leave that to the maintainers should you
agree with the patch.
Cheers,
Julian
[-- Attachment #2: uml-patch-defconfig-2.6.8.1-1 --]
[-- Type: text/plain, Size: 220 bytes --]
diff -r orig/linux-2.6.8.1/scripts/kconfig/confdata.c orig_defconfig/linux-2.6.8.1/scripts/kconfig/confdata.c
22,24d21
< "/lib/modules/$UNAME_RELEASE/.config",
< "/etc/kernel-config",
< "/boot/config-$UNAME_RELEASE",
next reply other threads:[~2004-10-11 22:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-11 22:22 Julian Scheid [this message]
2004-10-11 22:58 ` [uml-devel] Default kernel configuration on 2.6.x Michael Richardson
2004-10-11 23:47 ` BlaisorBlade
2004-10-11 23:46 ` BlaisorBlade
2004-10-12 0:41 ` Julian Scheid
2004-10-12 1:01 ` BlaisorBlade
2004-10-12 1:39 ` Julian Scheid
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=416B07AC.3030308@sektor37.de \
--to=julian@sektor37.de \
--cc=jdike@karaya.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.