From: Theodore Tso <tytso@mit.edu>
To: Andy Whitcroft <apw@shadowen.org>
Cc: Linus Torvalds <torvalds@osdl.org>,
Herbert Poetzl <herbert@13thfloor.at>,
Olaf Hering <olaf@aepfle.de>, Andi Kleen <ak@suse.de>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, Steve Fox <drfickle@us.ibm.com>
Subject: Re: 2.6.19-git13: uts banner changes break SLES9 (at least)
Date: Mon, 11 Dec 2006 15:15:52 -0500 [thread overview]
Message-ID: <20061211201552.GB20960@thunk.org> (raw)
In-Reply-To: <457DAF99.4050106@shadowen.org>
On Mon, Dec 11, 2006 at 07:20:57PM +0000, Andy Whitcroft wrote:
> I am afraid to report that this second version also fails for me, as you
> point out CIFS can break us if defined. In fact we used to get away
> with this on my test system due to ordering magic luck, I presume the
> move to __initdata has triggered this. Much as I agree that this is
> wrong we are still going to break people with this.
But does your problem go away if you compile CIFS as a module? If so,
then we're no worse off than before. Still, whoever wrote the SLES
initrd needs to receive 100 lashes with a wet noodle for not proposing
a more robust solution.
As far as whether or not it should be _mandatory_, to be able to pull
out the version information from an arbitrary bzImage file, can folks
agree that it would at least be a nice-to-have feature? Sometimes
when you're out in the field you don't know what you're faced with,
especially if you're dealing with a customer who likes to build their
own kernels, and who might not have, ah, a very well defined release
process. Sure, you can _call_ them incompetent, and it might even be
true, but wouldn't be nice if there was an easy way to look at a
bzImage file and be able to tell what kernel version it was built
from?
Clearly, if the goal is to make it easy to pull out, it will be
architecture specific, since it depends on the layout of the kernel
image file. At least for x86 and x86_64, though, there's an obvious
place for it --- in the first 512 bytes of the image, in what was
previously the floppy bootstrap code. Plenty of space there for a
100-150 bytes worth of version information.
- Ted
next prev parent reply other threads:[~2006-12-11 20:16 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-11 15:11 2.6.19-git13: uts banner changes break SLES9 (at least) Andy Whitcroft
2006-12-11 16:33 ` Olaf Hering
2006-12-11 16:44 ` Linus Torvalds
2006-12-11 16:52 ` Linus Torvalds
2006-12-11 18:04 ` Olaf Hering
2006-12-11 18:18 ` Olaf Hering
2006-12-11 18:26 ` Linus Torvalds
2006-12-11 18:29 ` Herbert Poetzl
2006-12-11 18:43 ` Linus Torvalds
2006-12-11 18:55 ` Olaf Hering
2006-12-11 19:11 ` Linus Torvalds
2006-12-11 22:04 ` Paul Mackerras
2006-12-12 0:05 ` David Miller
2006-12-12 9:10 ` Gerd Hoffmann
2006-12-11 19:20 ` Andy Whitcroft
2006-12-11 19:36 ` Linus Torvalds
2006-12-11 22:42 ` Andy Whitcroft
2006-12-11 19:37 ` Herbert Poetzl
2006-12-11 19:56 ` Olaf Hering
2006-12-11 20:05 ` Linus Torvalds
2006-12-11 20:09 ` Linus Torvalds
2006-12-11 20:21 ` Greg KH
2006-12-11 20:16 ` Olaf Hering
2006-12-11 20:15 ` Theodore Tso [this message]
2006-12-11 20:23 ` Arjan van de Ven
2006-12-11 21:16 ` H. Peter Anvin
2006-12-11 18:49 ` Olaf Hering
2006-12-12 12:23 ` Mach-O binary format support and Darwin syscall personality [Was: uts banner changes] Kyle Moffett
2006-12-12 16:23 ` Linus Torvalds
2006-12-12 17:56 ` Kyle Moffett
2006-12-12 18:20 ` Linus Torvalds
2006-12-12 22:34 ` Kyle Moffett
2006-12-12 22:38 ` Benjamin Herrenschmidt
2006-12-12 22:57 ` Linus Torvalds
2006-12-12 22:21 ` Benjamin Herrenschmidt
2006-12-15 12:53 ` Pavel Machek
2006-12-11 17:50 ` 2.6.19-git13: uts banner changes break SLES9 (at least) Olaf Hering
2006-12-11 17:57 ` Arjan van de Ven
2006-12-11 18:00 ` Olaf Hering
2006-12-11 18:08 ` Arjan van de Ven
2006-12-11 18:14 ` Olaf Hering
2006-12-11 19:03 ` Arjan van de Ven
2006-12-11 19:37 ` Jan Engelhardt
2006-12-11 18:19 ` Linus Torvalds
2006-12-11 18:40 ` Olaf Hering
2006-12-11 18:52 ` Linus Torvalds
2006-12-11 19:34 ` Jan Engelhardt
2006-12-11 21:15 ` H. Peter Anvin
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=20061211201552.GB20960@thunk.org \
--to=tytso@mit.edu \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=apw@shadowen.org \
--cc=drfickle@us.ibm.com \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=olaf@aepfle.de \
--cc=torvalds@osdl.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