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 cours
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:2
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.
--
Andrea
>> 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 so
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 to
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 wel
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 unsubs
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 u
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 wel
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 fro
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 pr
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 899
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, how
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 PROTECTED]>
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 i
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 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 configu
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
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 qu
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 d
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 ;)
>
> Ac
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 re
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 ke
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 i
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 t
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.
35 matches
Mail list logo
