Hi,
> That only gives you the version, not the whole version string, but you
> could put the whole string in such a location when adding such a
> facility to powerpc if you wanted to.
Hmm, as we have those fancy ELFNOTE macros now, can't we just the
version string into one?
cheers,
Gerd
--
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 09:04:41 +1100
> If there is a reliable way to get the version string, great, I'll use
> that.
FWIW, on sparc and sparc64 we have this information block for
the boot loader.
The first two instructions at the entry point simply branc
Linus Torvalds wrote:
On Mon, 11 Dec 2006, 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.
Olaf, will you admit that the SLES9 code is crap now?
Andy, does just replacing the "__initdata" with "const" fix
Linus Torvalds writes:
> On Mon, 11 Dec 2006, Olaf Hering wrote:
> >
> > arch/powerpc/boot/wrapper:156:version=`${CROSS}strings "$kernel" | grep
> > '^Linux version [-0-9.]' | \
>
> This is also obviously broken (and really sad), but actually ends up being
> better than what get_kernel_ver
Theodore Tso wrote:
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,
e
Linus Torvalds wrote:
- strongly encourage "get_kernel_version" users to just stop using that
crap. Ask the build system for the version instead or something, don't
expect to dig it out of the binary (if you create an RPM for any other
package, you sure as _hell_ don't start doing s
> 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?
I would really like for modinfo to work. it may not work on bzImage as
is, but it should work
On Mon, Dec 11, 2006 at 12:05:36PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 11 Dec 2006, Olaf Hering wrote:
> >
> > Quick, compile tested, patch below.
>
> No. We don't do this. We don't add TOTAL CRAP to the kernel just because
> somebody is being an idiot in user space.
>
> This is defini
On Mon, Dec 11, 2006 at 07:20:57PM +, 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 __in
On Mon, Dec 11, Olaf Hering wrote:
> On Mon, Dec 11, 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 presum
On Mon, 11 Dec 2006, Linus Torvalds wrote:
>
> So I would suggest SLES now show that support by fixing THEIR BUG.
Btw, if you still want to use "get_kernel_version" or whatever the broken
program was, I'd suggest:
- extend the check to verify that the version number that follows looks
va
On Mon, 11 Dec 2006, Olaf Hering wrote:
>
> Quick, compile tested, patch below.
No. We don't do this. We don't add TOTAL CRAP to the kernel just because
somebody is being an idiot in user space.
This is definitely a user space bug. It was a serious bug before, it just
wasn't obvious.
The th
On Mon, Dec 11, 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
On Dec 11 2006 19:14, Olaf Hering wrote:
>
>> (or in other words, why is SLES the only one with the problem?)
>
>Everyone has this "problem". Or how do you know what kernelrelease is
>inside a random ELF or bzImage binary?
Why would you even want to know that? (Stirring in the hornets nest,
just
On Mon, Dec 11, 2006 at 07:20:57PM +, Andy Whitcroft wrote:
> Linus Torvalds wrote:
> >
> >On Mon, 11 Dec 2006, Herbert Poetzl wrote:
> >>cool!
> >>
> >>should definitely work for all 'known' cases
> >
> >No it doesn't.
well, the 'method' not the actual patch, i.e.
you should be as lucky as be
On Mon, 11 Dec 2006, 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.
Olaf, will you admit that the SLES9 code is crap now?
Andy, does just replacing the "__initdata" with "const" fix it for you?
That
On Dec 11 2006 08:44, Linus Torvalds wrote:
>>
>> Please revert this change.
>
>Well, that "get_kernel_version" is definitely buggered, and should be
>fixed. And we do want the new behaviour for /proc/version.
>
>So I don't think we should revert it, but we should:
>
> - strongly encourage "get_
Linus Torvalds wrote:
On Mon, 11 Dec 2006, Herbert Poetzl wrote:
cool!
should definitely work for all 'known' cases
No it doesn't.
Do a
git grep '".*Linux version .*"'
on the kernel, and see just how CRAP that "get_kernel_version" test is,
and has always been.
But let's hope th
On Mon, 11 Dec 2006, Olaf Hering wrote:
>
> arch/powerpc/boot/wrapper:156:version=`${CROSS}strings "$kernel" | grep
> '^Linux version [-0-9.]' | \
This is also obviously broken (and really sad), but actually ends up being
better than what get_kernel_version apparently does, by at least ad
>
> > (or in other words, why is SLES the only one with the problem?)
>
> Everyone has this "problem". Or how do you know what kernelrelease is
> inside a random ELF or bzImage binary?
I doubt anyone else will let it come to the "random" stage
--
if you want to mail me at work (you don't), u
On Mon, Dec 11, Linus Torvalds wrote:
> Do a
>
> git grep '".*Linux version .*"'
>
> on the kernel, and see just how CRAP that "get_kernel_version" test is,
> and has always been.
>
> But let's hope that CIFS is never compiled into a SLES kernel. Because
> this isn't worth fixing at tha
On Mon, 11 Dec 2006, Herbert Poetzl wrote:
>
> cool!
>
> should definitely work for all 'known' cases
No it doesn't.
Do a
git grep '".*Linux version .*"'
on the kernel, and see just how CRAP that "get_kernel_version" test is,
and has always been.
But let's hope that CIFS is never
On Mon, Dec 11, Linus Torvalds wrote:
>
>
> On Mon, 11 Dec 2006, Olaf Hering wrote:
> >
> > Hmm, even moving this to linux_banner doesnt work, just because
> > __initdata is in a different section.
>
> Heh. Let's just change the "version_read_proc" string to not trigger.
>
> Something like th
On Mon, 11 Dec 2006, Olaf Hering wrote:
>
> Of course I could tell it every time what the kernelrelease is, but why
> do I have to?
Because right now, YOUR PIECE OF CRAP IS BUGGY.
Look here, I'm not going to bother explain it to you any more. Do the
git grep '".*Linux version .*"'
th
On Mon, Dec 11, Linus Torvalds wrote:
> "Suppose I send you some random vmlinux binary."
>
> THAT is the problem.
Erm no, thats reality and happens every day. git-bisect a modular kernel
on one box and test it on another. The mkinitrd (and depmod) wants to know
where to look for modules.
O
On Mon, Dec 11, 2006 at 10:26:13AM -0800, Linus Torvalds wrote:
>
>
> On Mon, 11 Dec 2006, Olaf Hering wrote:
> >
> > Hmm, even moving this to linux_banner doesnt work, just because
> > __initdata is in a different section.
>
> Heh. Let's just change the "version_read_proc" string to not trigge
On Mon, 11 Dec 2006, Olaf Hering wrote:
>
> Hmm, even moving this to linux_banner doesnt work, just because
> __initdata is in a different section.
Heh. Let's just change the "version_read_proc" string to not trigger.
Something like this instead (which replaces the "Linux" with "%s" in
/proc,
On Mon, 11 Dec 2006, Olaf Hering wrote:
>
> SLES7 or SLES11 is not any different than SLES9 in that respect.
> Suppose I send you some random vmlinux binary. How do you (you as in linus.sh)
> know what 'uname -r' is inside this binary?
> There are surely many many ways to pass that info. Having
On Mon, Dec 11, Olaf Hering wrote:
> On Mon, Dec 11, Linus Torvalds wrote:
>
> > +static char __initdata linux_banner[] =
> > + "Linux version " UTS_RELEASE
> > + " (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
> > + " (" LINUX_COMPILER ")"
> > + " " UTS_VERSION "\n";
>
> main.o gets li
On Mon, Dec 11, Arjan van de Ven wrote:
> strings doesn't work there, it's a compressed image!
Thats why get_kernel_version calls gzip.
> also... can't you just know which vmlinux it is in the first place?
No, you cant.
> (or in other words, why is SLES the only one with the problem?)
Everyone
On Mon, Dec 11, Linus Torvalds wrote:
> +static char __initdata linux_banner[] =
> + "Linux version " UTS_RELEASE
> + " (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ")"
> + " (" LINUX_COMPILER ")"
> + " " UTS_VERSION "\n";
main.o gets linked after misc.o, so this will not work. Havi
On Mon, 2006-12-11 at 19:00 +0100, Olaf Hering wrote:
> On Mon, Dec 11, Arjan van de Ven wrote:
>
> > it's for sure the most ugly one. I could see the use of having modinfo
> > work on the vmlinux, and have the vmlinux have a VERMAGIC as well. It's
> > only a simple elf section after all, and a he
On Mon, Dec 11, Arjan van de Ven wrote:
> it's for sure the most ugly one. I could see the use of having modinfo
> work on the vmlinux, and have the vmlinux have a VERMAGIC as well. It's
> only a simple elf section after all, and a heck of a lot more defined
> and standard...
Just go for it. Reme
On Mon, 2006-12-11 at 18:50 +0100, Olaf Hering wrote:
> On Mon, Dec 11, Linus Torvalds wrote:
> > What crud. I'm even slightly inclined to just let SLES9 be broken, just to
> > let people know how unacceptable it is to look for strings in kernel
> > binaries. But sadly, I don't think the poor us
On Mon, Dec 11, Linus Torvalds wrote:
> What crud. I'm even slightly inclined to just let SLES9 be broken, just to
> let people know how unacceptable it is to look for strings in kernel
> binaries. But sadly, I don't think the poor users should be penalized for
> some idiotic SLES developers ba
On Mon, 11 Dec 2006, Linus Torvalds wrote:
>
> What crud. I'm even slightly inclined to just let SLES9 be broken, just to
> let people know how unacceptable it is to look for strings in kernel
> binaries. But sadly, I don't think the poor users should be penalized for
> some idiotic SLES deve
On Mon, 11 Dec 2006, Olaf Hering wrote:
>
> Please revert this change.
Well, that "get_kernel_version" is definitely buggered, and should be
fixed. And we do want the new behaviour for /proc/version.
So I don't think we should revert it, but we should:
- use separate strings for /proc/versi
On Mon, Dec 11, Andy Whitcroft wrote:
> # get_kernel_version /boot/vmlinuz-autobench
> %s
It expects the content from `cat /proc/version`:
...
for (i = 0; i < in; i++)
if (buffer[i] == 'L' && buffer[i+1] == 'i' &&
buffer[i+2] == 'n' && buffer[i+3] == 'u' &&
test.kernel.org testing seems to have shaken out a problem with the
kernel banner changing, introduced by this commit:
[PATCH] Fix linux banner utsname information
commit a2ee8649ba6d71416712e798276bf7c40b64e6e5
We first noticed it with 2.6.19-git13 as we use this version string
39 matches
Mail list logo
