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
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
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
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,
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
> 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
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
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
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
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
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
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
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
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
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
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
>
> > (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),
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
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
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 .*"'
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.
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
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
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
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?)
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.
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
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.
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
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
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
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
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
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
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'
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/version
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
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 bad
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 users
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.
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. Having both as
globals
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 heck of a
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, 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 linked after misc.o, so this
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 a
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, and
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 trigger.
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.
Of
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 this instead
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 .*'
thing,
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 that point, and
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
(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), use arjan
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 adding
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 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
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 should
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 before, if the
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 add a
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 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
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 presume the
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
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 definitely a user
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
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
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,
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_version
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 it
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 branch
77 matches
Mail list logo
