On Jan 11 2007 18:39, Segher Boessenkool wrote:
>
>> > ../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
>> > objcopy: stvfMiji: Permission denied
>> >
>> > Why does it want to create a file there? This one works better:
>>
>> objcopy works in-place when only one file argument is passed.
../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
objcopy: stvfMiji: Permission denied
Why does it want to create a file there? This one works better:
objcopy works in-place when only one file argument is passed.
Yeah. The >(...) syntax in my example provides such a file;
of
On Thu, 11 Jan 2007, Roman Zippel wrote:
>
> Unless the SuSE tool is completely stupid, it should actually work:
>
> $ strings vmlinux | grep "Linux version"
> Linux version 2.6.20-rc3-git7 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115
> (prerelease) (Debian 4.1.1-21)) #7 SMP Wed Jan 10
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> ../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
> objcopy: stvfMiji: Permission denied
>
> Why does it want to create a file there? This one works better:
objcopy works in-place when only one file argument is passed.
Andreas.
--
>> With such a change, you would not need to grep for it. You could use
>> binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
>> Maybe not the prettiest output, but guaranteed to contain only the
>> banner.
>
> objcopy -j .rodata.uts -O binary vmlinux >(the-checker-script)
For
Roman Zippel wrote:
> Hi,
>
> On Wed, 10 Jan 2007, Linus Torvalds wrote:
>
>> This part:
>>
>> const char __init linux_banner[] =
>>
>> CANNOT work, because the stupid SuSE tool that look into the kernel binary
>> searches for "Linux version " as the thing, and as such the "linux_banner"
Hi,
On Wed, 10 Jan 2007, Linus Torvalds wrote:
> This part:
>
> const char __init linux_banner[] =
>
> CANNOT work, because the stupid SuSE tool that look into the kernel binary
> searches for "Linux version " as the thing, and as such the "linux_banner"
> has to be the _first_ thing
Linus Torvalds wrote:
>
> On Wed, 10 Jan 2007, Linus Torvalds wrote:
>> Which is why "__init" is wrong. It causes the linker to either put it at
>> the end of the thing (which would break the SuSE tool). Alternatively it
>> causes section mismatch problems ("init" and "const" don't work that
Linus Torvalds wrote:
On Wed, 10 Jan 2007, Linus Torvalds wrote:
Which is why __init is wrong. It causes the linker to either put it at
the end of the thing (which would break the SuSE tool). Alternatively it
causes section mismatch problems (init and const don't work that well
Hi,
On Wed, 10 Jan 2007, Linus Torvalds wrote:
This part:
const char __init linux_banner[] =
CANNOT work, because the stupid SuSE tool that look into the kernel binary
searches for Linux version as the thing, and as such the linux_banner
has to be the _first_ thing to trigger
Roman Zippel wrote:
Hi,
On Wed, 10 Jan 2007, Linus Torvalds wrote:
This part:
const char __init linux_banner[] =
CANNOT work, because the stupid SuSE tool that look into the kernel binary
searches for Linux version as the thing, and as such the linux_banner
has to be the
With such a change, you would not need to grep for it. You could use
binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
Maybe not the prettiest output, but guaranteed to contain only the
banner.
objcopy -j .rodata.uts -O binary vmlinux (the-checker-script)
For some reason
Jan Engelhardt [EMAIL PROTECTED] writes:
../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
objcopy: stvfMiji: Permission denied
Why does it want to create a file there? This one works better:
objcopy works in-place when only one file argument is passed.
Andreas.
--
Andreas
On Thu, 11 Jan 2007, Roman Zippel wrote:
Unless the SuSE tool is completely stupid, it should actually work:
$ strings vmlinux | grep Linux version
Linux version 2.6.20-rc3-git7 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115
(prerelease) (Debian 4.1.1-21)) #7 SMP Wed Jan 10 14:20:10
../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
objcopy: stvfMiji: Permission denied
Why does it want to create a file there? This one works better:
objcopy works in-place when only one file argument is passed.
Yeah. The (...) syntax in my example provides such a file;
of
On Jan 11 2007 18:39, Segher Boessenkool wrote:
../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
objcopy: stvfMiji: Permission denied
Why does it want to create a file there? This one works better:
objcopy works in-place when only one file argument is passed.
Yeah. The
With such a change, you would not need to grep for it. You could use
binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
Maybe not the prettiest output, but guaranteed to contain only the
banner.
objcopy -j .rodata.uts -O binary vmlinux >(the-checker-script)
Segher
-
To
On Jan 10 2007 21:02, Olaf Hering wrote:
>On Wed, Jan 10, Olaf Hering wrote:
>
>with such a change, it will always be first. Tested on powerpc.
>I could even add an ELF parser and look for the first bytes in the
>.rodata section.
With such a change, you would not need to grep for it. You could
On Wed, 10 Jan 2007, Olaf Hering wrote:
>
> On Wed, Jan 10, Linus Torvalds wrote:
>
> > Grr.
>
> It did work for me for some reason, but I was wondering why it did work.
Because you didn't have CIFS compiled in? Right now that's the only other
module that would trigger that particular string
Linus Torvalds wrote:
>
> On Wed, 10 Jan 2007, Linus Torvalds wrote:
>> Which is why "__init" is wrong. It causes the linker to either put it at
>> the end of the thing (which would break the SuSE tool). Alternatively it
>> causes section mismatch problems ("init" and "const" don't work that
On Wed, Jan 10, Olaf Hering wrote:
> On Wed, Jan 10, Linus Torvalds wrote:
>
> > Grr.
>
> It did work for me for some reason, but I was wondering why it did work.
with such a change, it will always be first. Tested on powerpc.
I could even add an ELF parser and look for the first bytes in the
On Wed, 10 Jan 2007, Linus Torvalds wrote:
>
> Which is why "__init" is wrong. It causes the linker to either put it at
> the end of the thing (which would break the SuSE tool). Alternatively it
> causes section mismatch problems ("init" and "const" don't work that well
> together), in which
On Wed, Jan 10, Linus Torvalds wrote:
> Grr.
It did work for me for some reason, but I was wondering why it did work.
Cant we just invent a .data.uts section and put that into the
i386/x86_64/ia64/s390/powerpc vmlinux.lds.S files?
'"Linux version " UTS_RELEASE' in version.c
-
To unsubscribe
On Wed, 10 Jan 2007, Jean Delvare wrote:
>
> This fixes the problem I reported. Thanks Roman!
>
> Linus, Andrew, if Roman's patch looks OK to you, can it please be
> applied before 2.6.20 is released?
I applied it, but looking closer at it, it becomes clear that Roman didn't
understand the
Hi Roman,
On Wed, 10 Jan 2007 14:45:28 +0100 (CET), Roman Zippel wrote:
> On Tue, 9 Jan 2007, Jean Delvare wrote:
>
> > I tried a git bisect to find out what commit was reponsible for it, and
> > the winner is...
> >
> > 8993780a6e44fb4e7ed34e33458506a775356c6e is first bad commit
> > commit
Hi Martin,
On Wed, 10 Jan 2007 08:52:24 -0800, Martin J. Bligh wrote:
> Andrew Morton wrote:
> > I use it pretty commonly to answer the question "did I remember to install
> > that new kernel I just built before I rebooted"? By comparing `uname -a'
> > with $TOPDIR/.version.
>
> Yup, we need to
Andrew Morton wrote:
On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Tue, 9 Jan 2007, Andrew Morton wrote:
This new behavior of the kernel build system is likely to
make developers angry pretty quickly.
That might motivate them to fix it ;)
Actually,
On Wed, Jan 10, Roman Zippel wrote:
> [PATCH] fix linux banner format string
>
> Revert previous attempts at messing with the linux banner string and
> simply use a separate format string for proc.
>
> Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
Acked-by: Olaf Hering <[EMAIL PROTECTED]>
Hi,
On Tue, 9 Jan 2007, Jean Delvare wrote:
> I tried a git bisect to find out what commit was reponsible for it, and
> the winner is...
>
> 8993780a6e44fb4e7ed34e33458506a775356c6e is first bad commit
> commit 8993780a6e44fb4e7ed34e33458506a775356c6e
> Author: Linus Torvalds <[EMAIL
On Jan 9 2007 15:21, Linus Torvalds wrote:
>
>Actually, how about just removing the incrementing version count entirely?
>
>I realize that it's really really old, and has been there basically since
>day one, but on the other hand, it's old not because it's fundamentally
>important, but because
Hi Linus, Andrew,
On Tue, 9 Jan 2007 15:25:34 -0800, Andrew Morton wrote:
> On Tue, 9 Jan 2007 15:21:51 -0800, Linus Torvalds wrote:
> > Actually, how about just removing the incrementing version count entirely?
>
> I use it pretty commonly to answer the question "did I remember to install
> that
Hi Linus, Andrew,
On Tue, 9 Jan 2007 15:25:34 -0800, Andrew Morton wrote:
On Tue, 9 Jan 2007 15:21:51 -0800, Linus Torvalds wrote:
Actually, how about just removing the incrementing version count entirely?
I use it pretty commonly to answer the question did I remember to install
that new
On Jan 9 2007 15:21, Linus Torvalds wrote:
Actually, how about just removing the incrementing version count entirely?
I realize that it's really really old, and has been there basically since
day one, but on the other hand, it's old not because it's fundamentally
important, but because it's
Hi,
On Tue, 9 Jan 2007, Jean Delvare wrote:
I tried a git bisect to find out what commit was reponsible for it, and
the winner is...
8993780a6e44fb4e7ed34e33458506a775356c6e is first bad commit
commit 8993780a6e44fb4e7ed34e33458506a775356c6e
Author: Linus Torvalds [EMAIL PROTECTED]
Date:
On Wed, Jan 10, Roman Zippel wrote:
[PATCH] fix linux banner format string
Revert previous attempts at messing with the linux banner string and
simply use a separate format string for proc.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
Acked-by: Olaf Hering [EMAIL PROTECTED]
-
To
Andrew Morton wrote:
On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Tue, 9 Jan 2007, Andrew Morton wrote:
This new behavior of the kernel build system is likely to
make developers angry pretty quickly.
That might motivate them to fix it ;)
Actually, how
Hi Martin,
On Wed, 10 Jan 2007 08:52:24 -0800, Martin J. Bligh wrote:
Andrew Morton wrote:
I use it pretty commonly to answer the question did I remember to install
that new kernel I just built before I rebooted? By comparing `uname -a'
with $TOPDIR/.version.
Yup, we need to do the
Hi Roman,
On Wed, 10 Jan 2007 14:45:28 +0100 (CET), Roman Zippel wrote:
On Tue, 9 Jan 2007, Jean Delvare wrote:
I tried a git bisect to find out what commit was reponsible for it, and
the winner is...
8993780a6e44fb4e7ed34e33458506a775356c6e is first bad commit
commit
On Wed, 10 Jan 2007, Jean Delvare wrote:
This fixes the problem I reported. Thanks Roman!
Linus, Andrew, if Roman's patch looks OK to you, can it please be
applied before 2.6.20 is released?
I applied it, but looking closer at it, it becomes clear that Roman didn't
understand the
On Wed, Jan 10, Linus Torvalds wrote:
Grr.
It did work for me for some reason, but I was wondering why it did work.
Cant we just invent a .data.uts section and put that into the
i386/x86_64/ia64/s390/powerpc vmlinux.lds.S files?
'Linux version UTS_RELEASE' in version.c
-
To unsubscribe from
On Wed, 10 Jan 2007, Linus Torvalds wrote:
Which is why __init is wrong. It causes the linker to either put it at
the end of the thing (which would break the SuSE tool). Alternatively it
causes section mismatch problems (init and const don't work that well
together), in which case it
On Wed, Jan 10, Olaf Hering wrote:
On Wed, Jan 10, Linus Torvalds wrote:
Grr.
It did work for me for some reason, but I was wondering why it did work.
with such a change, it will always be first. Tested on powerpc.
I could even add an ELF parser and look for the first bytes in the
Linus Torvalds wrote:
On Wed, 10 Jan 2007, Linus Torvalds wrote:
Which is why __init is wrong. It causes the linker to either put it at
the end of the thing (which would break the SuSE tool). Alternatively it
causes section mismatch problems (init and const don't work that well
On Wed, 10 Jan 2007, Olaf Hering wrote:
On Wed, Jan 10, Linus Torvalds wrote:
Grr.
It did work for me for some reason, but I was wondering why it did work.
Because you didn't have CIFS compiled in? Right now that's the only other
module that would trigger that particular string in
On Jan 10 2007 21:02, Olaf Hering wrote:
On Wed, Jan 10, Olaf Hering wrote:
with such a change, it will always be first. Tested on powerpc.
I could even add an ELF parser and look for the first bytes in the
.rodata section.
With such a change, you would not need to grep for it. You could use
With such a change, you would not need to grep for it. You could use
binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
Maybe not the prettiest output, but guaranteed to contain only the
banner.
objcopy -j .rodata.uts -O binary vmlinux (the-checker-script)
Segher
-
To
Hi Luca,
On Tue, 9 Jan 2007 22:55:27 +0100, Luca Tettamanti wrote:
> Jean Delvare <[EMAIL PROTECTED]> ha scritto:
> > Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> > an incremented version number, whether there has actually been any
> > change done to the code or
On Tue, Jan 09, 2007 at 03:25:34PM -0800, Andrew Morton wrote:
> On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 9 Jan 2007, Andrew Morton wrote:
> > >
> > > > This new behavior of the kernel build system is likely to
> > > > make developers
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Tue, 9 Jan 2007, Andrew Morton wrote:
> > >
> > > > This new behavior of the kernel build system is likely to
> > > > make developers angry pretty
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 9 Jan 2007 15:25:34 -0800
> On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 9 Jan 2007, Andrew Morton wrote:
> > >
> > > > This new behavior of the kernel build system is likely to
> > > > make
On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 9 Jan 2007, Andrew Morton wrote:
> >
> > > This new behavior of the kernel build system is likely to
> > > make developers angry pretty quickly.
> >
> > That might motivate them to fix it ;)
>
>
Hi Jean !
On Tue, Jan 09, 2007 at 10:20:57AM +0100, Jean Delvare wrote:
> Hi all,
>
> Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> an incremented version number, whether there has actually been any
> change done to the code or configuration or not. This increases the
On Tue, 9 Jan 2007, Andrew Morton wrote:
>
> > This new behavior of the kernel build system is likely to
> > make developers angry pretty quickly.
>
> That might motivate them to fix it ;)
Actually, how about just removing the incrementing version count entirely?
I realize that it's really
Jean Delvare <[EMAIL PROTECTED]> ha scritto:
> Hi all,
Hi Jean,
> Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> an incremented version number, whether there has actually been any
> change done to the code or configuration or not. This increases the
> build time quite a
On Tue, 9 Jan 2007 21:44:21 +0100
Jean Delvare <[EMAIL PROTECTED]> wrote:
> So, Linus, Andrew, can you please take a look and revert or fix what
> needs to be?
Am afraid to touch it. Sam should be back on deck soon and will hopefully
have time to fix this stuff up.
> This new behavior of the
Hi Andrey,
On Tue, 09 Jan 2007 20:05:49 +0300, Andrey Borzenkov wrote:
> Jean Delvare wrote:
> > Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> > an incremented version number, whether there has actually been any
> > change done to the code or configuration or not. This
Jean Delvare wrote:
> Hi all,
>
> Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> an incremented version number, whether there has actually been any
> change done to the code or configuration or not. This increases the
> build time quite a bit.
>
> I've tracked it down
On Tuesday 09 January 2007 04:20, Jean Delvare wrote:
>Hi all,
>
>Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
>an incremented version number, whether there has actually been any
>change done to the code or configuration or not. This increases the
>build time quite a bit.
Hi all,
Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
an incremented version number, whether there has actually been any
change done to the code or configuration or not. This increases the
build time quite a bit.
I've tracked it down to include/linux/compile.h always
Hi all,
Since 2.6.20-rc1 or so, running make always builds a new kernel with
an incremented version number, whether there has actually been any
change done to the code or configuration or not. This increases the
build time quite a bit.
I've tracked it down to include/linux/compile.h always being
On Tuesday 09 January 2007 04:20, Jean Delvare wrote:
Hi all,
Since 2.6.20-rc1 or so, running make always builds a new kernel with
an incremented version number, whether there has actually been any
change done to the code or configuration or not. This increases the
build time quite a bit.
I've
Jean Delvare wrote:
Hi all,
Since 2.6.20-rc1 or so, running make always builds a new kernel with
an incremented version number, whether there has actually been any
change done to the code or configuration or not. This increases the
build time quite a bit.
I've tracked it down to
Hi Andrey,
On Tue, 09 Jan 2007 20:05:49 +0300, Andrey Borzenkov wrote:
Jean Delvare wrote:
Since 2.6.20-rc1 or so, running make always builds a new kernel with
an incremented version number, whether there has actually been any
change done to the code or configuration or not. This increases
On Tue, 9 Jan 2007 21:44:21 +0100
Jean Delvare [EMAIL PROTECTED] wrote:
So, Linus, Andrew, can you please take a look and revert or fix what
needs to be?
Am afraid to touch it. Sam should be back on deck soon and will hopefully
have time to fix this stuff up.
This new behavior of the kernel
Jean Delvare [EMAIL PROTECTED] ha scritto:
Hi all,
Hi Jean,
Since 2.6.20-rc1 or so, running make always builds a new kernel with
an incremented version number, whether there has actually been any
change done to the code or configuration or not. This increases the
build time quite a bit.
On Tue, 9 Jan 2007, Andrew Morton wrote:
This new behavior of the kernel build system is likely to
make developers angry pretty quickly.
That might motivate them to fix it ;)
Actually, how about just removing the incrementing version count entirely?
I realize that it's really really
Hi Jean !
On Tue, Jan 09, 2007 at 10:20:57AM +0100, Jean Delvare wrote:
Hi all,
Since 2.6.20-rc1 or so, running make always builds a new kernel with
an incremented version number, whether there has actually been any
change done to the code or configuration or not. This increases the
build
On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Tue, 9 Jan 2007, Andrew Morton wrote:
This new behavior of the kernel build system is likely to
make developers angry pretty quickly.
That might motivate them to fix it ;)
Actually, how about
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 9 Jan 2007 15:25:34 -0800
On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Tue, 9 Jan 2007, Andrew Morton wrote:
This new behavior of the kernel build system is likely to
make developers angry
Andrew Morton [EMAIL PROTECTED] writes:
On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Tue, 9 Jan 2007, Andrew Morton wrote:
This new behavior of the kernel build system is likely to
make developers angry pretty quickly.
That
On Tue, Jan 09, 2007 at 03:25:34PM -0800, Andrew Morton wrote:
On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Tue, 9 Jan 2007, Andrew Morton wrote:
This new behavior of the kernel build system is likely to
make developers angry pretty quickly.
Hi Luca,
On Tue, 9 Jan 2007 22:55:27 +0100, Luca Tettamanti wrote:
Jean Delvare [EMAIL PROTECTED] ha scritto:
Since 2.6.20-rc1 or so, running make always builds a new kernel with
an incremented version number, whether there has actually been any
change done to the code or configuration or
72 matches
Mail list logo
