From: Mike Auty <ikelos@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
Date: Sun, 30 Aug 2009 17:18:22 +0100 [thread overview]
Message-ID: <4A9AA64E.6020401@gentoo.org> (raw)
In-Reply-To: <20090830154520.GA32569@linux1>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
William Hubbs wrote:
> I agree here. The eclass should check /proc/config.gz.
> Also, another reason to use the eclass is it respects KBUILD_OUTPUT if
> it is set.
- From the indenting I can't tell if you wrote this or not, however, we
need to differentiate between running and build time environments.
Ebuilding is a build-time process. That means the running kernel isn't
important, since we're not running udev, we're just building it. When
the machine is next rebooted, we could be using a completely different
kernel (or even one that hasn't been installed yet). We should only
care about the build-time kernel when we're building, which the user has
to specify (which they do implicitly by using /usr/src/linux, or
explicitly by using KBUILD_OUTPUT or another environment variable).
If you go by the running kernel, then you're requiring people to reboot
their computers before they can build software for a kernel they're
about to run. That simply ensures downtime on a potentially critical
service, and moreover it's an unnecessary constraint. The existing udev
can continue running until the machine is rebooted without a problem.
When the machine restarts *any* kernel could be chosen, and build time
checks won't help prevent a bad kernel from being booted. That's why
the linux-info.eclass does the checks it currently does, and *doesn't*
check /proc/config.gz and *doesn't* check /$(uname -r)/ directories...
So in summary:
* Check the running kernel if you're about to run.
* Check the kernel the user's chosen to build against if you're about to
build, using linux-info.
If the ebuild restarts the service (causing a reread off disk, rather
than just a reread of the rules) then fine, use the check to disable the
restart, and/or warn the user, but don't stop the user from building the
software.
You can also put a check in the init.d, but it just creates the
possibility that the check is wrong when udev could potentially still
run. I'd simply try running udev and check if it exits or errors as
expected. Only if it doesn't exit or error when it should would I add
checks to the initscript, and even then I'd suggest fixing the code to
error correctly, over adding our own checks in...
Mike 5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAkqapk4ACgkQu7rWomwgFXqDbACgtYdXtmlgo6JA49o9on111XPE
Y/QAnROtzEhAUg0ML9J+nd6rTvKfZeFz
=pbOj
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2009-08-30 11:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-30 14:11 [gentoo-dev] About udev-145: new features / extras and kernel requirements Matthias Schwarzott
2009-08-30 14:24 ` Arun Raghavan
2009-08-30 15:26 ` [gentoo-dev] " Duncan
2009-08-30 14:46 ` [gentoo-dev] " Nirbheek Chauhan
2009-08-30 15:45 ` William Hubbs
2009-08-30 16:18 ` Mike Auty [this message]
2009-08-31 15:46 ` Jeremy Olexa
2009-08-31 4:25 ` Lars Wendler
2009-08-30 15:05 ` Bruno
2009-08-30 19:20 ` Robin H. Johnson
2009-11-09 16:35 ` Mart Raudsepp
2009-11-12 9:08 ` Matthias Schwarzott
2009-11-09 19:22 ` Daniel Drake
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=4A9AA64E.6020401@gentoo.org \
--to=ikelos@gentoo.org \
--cc=gentoo-dev@lists.gentoo.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