Re: [PATCH] Compress kernel modules on installation.

On Mon, Feb 25, 2008 at 11:19 PM, Willy Tarreau: > > On Mon, Feb 25, 2008 at 11:17:23PM +0100, Oleg Verych wrote: > > On Mon, Feb 25, 2008 at 10:42 PM, Steve Brokenshire: > > > Hi, > > > > > > (I've sent this to the linux-kbuild and linux-kern

Re: [PATCH] Compress kernel modules on installation.

On Mon, Feb 25, 2008 at 10:42 PM, Steve Brokenshire: > Hi, > > (I've sent this to the linux-kbuild and linux-kernel lists as this > patch modifies the Makefile.modinst file. I also don't subscribe to the > linux-kbuild and linux-kernel mailing lists so can I have any replies > CC'ed to me

Re: [PATCH] Compress kernel modules on installation.

On Mon, Feb 25, 2008 at 10:42 PM, Steve Brokenshire: Hi, (I've sent this to the linux-kbuild and linux-kernel lists as this patch modifies the Makefile.modinst file. I also don't subscribe to the linux-kbuild and linux-kernel mailing lists so can I have any replies CC'ed to me please)

Re: [PATCH] Compress kernel modules on installation.

On Mon, Feb 25, 2008 at 11:19 PM, Willy Tarreau: On Mon, Feb 25, 2008 at 11:17:23PM +0100, Oleg Verych wrote: On Mon, Feb 25, 2008 at 10:42 PM, Steve Brokenshire: Hi, (I've sent this to the linux-kbuild and linux-kernel lists as this patch modifies the Makefile.modinst file

Re: [PATCH] kbuild: fix make V=1

On Feb 12, 2008 5:18 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Tuesday 12 February 2008, Oleg Verych wrote: [] > > > i dont see how yours is more efficient when it always runs echo. > > > > Oh, this? It's like doing syscall for every write to "/

Re: [PATCH] kbuild: fix make V=1

On Feb 12, 2008 4:07 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote: [] > > - quiet_chk_filechk = echo ' CHK $@' > > -silent_chk_filechk = : > > - quiet_upd_filechk = echo ' UPD $@' > > -silent_upd_filechk = : > > +quiet_chk_filechk = ' CHK $@' > > +quiet_upd_filechk = ' UPD $@'

Re: [PATCH] kbuild: fix make V=1

On Tue, Feb 12, 2008 at 09:56:05AM +0100, Sam Ravnborg wrote: > On Tue, Feb 12, 2008 at 12:38:24AM +0100, Oleg Verych wrote: > > * Date: Mon, 11 Feb 2008 17:47:09 +0100 > > [] > > > Mike spotted another missing thing from his initial > > > patch so I fold

Re: [PATCH] kbuild: fix make V=1

On Tue, Feb 12, 2008 at 09:56:05AM +0100, Sam Ravnborg wrote: On Tue, Feb 12, 2008 at 12:38:24AM +0100, Oleg Verych wrote: * Date: Mon, 11 Feb 2008 17:47:09 +0100 [] Mike spotted another missing thing from his initial patch so I folded it into the fix and pushed out a new kbuild.git

Re: [PATCH] kbuild: fix make V=1

On Feb 12, 2008 5:18 PM, Mike Frysinger [EMAIL PROTECTED] wrote: On Tuesday 12 February 2008, Oleg Verych wrote: [] i dont see how yours is more efficient when it always runs echo. Oh, this? It's like doing syscall for every write to /dev/null. how is that relevant ? there is no /dev

Re: [PATCH] kbuild: fix make V=1

On Feb 12, 2008 4:07 PM, Mike Frysinger [EMAIL PROTECTED] wrote: [] - quiet_chk_filechk = echo ' CHK $@' -silent_chk_filechk = : - quiet_upd_filechk = echo ' UPD $@' -silent_upd_filechk = : +quiet_chk_filechk = ' CHK $@' +quiet_upd_filechk = ' UPD $@' + define

Re: [PATCH] kbuild: fix make V=1

* Date: Mon, 11 Feb 2008 17:47:09 +0100 [] > Mike spotted another missing thing from his initial > patch so I folded it into the fix and pushed out > a new kbuild.git tree. > > See updated patch below. > > Sam Sam, do you agree my fix was more reliable (yea, not only efficient:)? On cost

[patch] Re: Linux 2.6.25-rc1 , syntax error near unexpected token `;'

>> set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE http://mid.gmane.org/[EMAIL PROTECTED] _ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [PATCH] kbuild: fix make V=1

* Date: Mon, 11 Feb 2008 17:47:09 +0100 [] Mike spotted another missing thing from his initial patch so I folded it into the fix and pushed out a new kbuild.git tree. See updated patch below. Sam Sam, do you agree my fix was more reliable (yea, not only efficient:)? On cost of one

[patch] Re: Linux 2.6.25-rc1 , syntax error near unexpected token `;'

set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE http://mid.gmane.org/[EMAIL PROTECTED] _ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: translations (Re: Kbuild update)

@ Wed, Jan 09, 2008 at 10:22:08AM +0800, WANG Cong wrote: > > >"I will use ... > >http://images.google.cz/images?svnum=100=1=cs=firefox-a=org.mozilla%3Acs%3Aofficial=I+will+use+Google+before=Hledat+obr%C3%A1zky > >... for making translations..." >

Re: translations (Re: Kbuild update)

@ Wed, Jan 09, 2008 at 10:22:08AM +0800, WANG Cong wrote: I will use ... http://images.google.cz/images?svnum=100um=1hl=csclient=firefox-arls=org.mozilla%3Acs%3Aofficialq=I+will+use+Google+beforebtnG=Hledat+obr%C3%A1zky ... for making translations...

translations (Re: Kbuild update)

On Sun, Jan 06, 2008 at 10:26:06PM +0800, WANG Cong wrote: > > >> It sort of stopped at one point due to missing integration in mainline. > >> What I refer to is mostly the mconf.c bits, but I would also like to > >> see what lkml says to a sample of .po files included in the kernel > >> for a

translations (Re: Kbuild update)

On Sun, Jan 06, 2008 at 10:26:06PM +0800, WANG Cong wrote: It sort of stopped at one point due to missing integration in mainline. What I refer to is mostly the mconf.c bits, but I would also like to see what lkml says to a sample of .po files included in the kernel for a number of

stuff (Re: Kbuild update)

On Jan 4, 2008 9:09 PM, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Jan 4 2008 20:43, Sam Ravnborg wrote: > >On Thu, Jan 03, 2008 at 11:33:44PM +0100, Jan Engelhardt wrote: > >> > >> On Jan 3 2008 22:32, Sam Ravnborg wrote: > >> > > >> >On top of this I have my personal todo items such as: >

stuff (Re: Kbuild update)

On Jan 4, 2008 9:09 PM, Jan Engelhardt [EMAIL PROTECTED] wrote: On Jan 4 2008 20:43, Sam Ravnborg wrote: On Thu, Jan 03, 2008 at 11:33:44PM +0100, Jan Engelhardt wrote: On Jan 3 2008 22:32, Sam Ravnborg wrote: On top of this I have my personal todo items such as: - modern ncurses

Re: mkasm-offsets.sh ?

On Dec 5, 2007 6:14 PM, Hollis Blanchard <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-12-05 at 07:49 +, Oleg Verych wrote: > > On Dec 4, 2007 9:59 PM, Hollis Blanchard <[EMAIL PROTECTED]> wrote: > > > Hi, I found this thread: http://lkml.org/lkml/2007/4/1/237

Re: mkasm-offsets.sh ?

On Dec 5, 2007 6:14 PM, Hollis Blanchard [EMAIL PROTECTED] wrote: On Wed, 2007-12-05 at 07:49 +, Oleg Verych wrote: On Dec 4, 2007 9:59 PM, Hollis Blanchard [EMAIL PROTECTED] wrote: Hi, I found this thread: http://lkml.org/lkml/2007/4/1/237 I guess the complete patch was never

Re: mkasm-offsets.sh ?

On Dec 4, 2007 9:59 PM, Hollis Blanchard <[EMAIL PROTECTED]> wrote: > Hi, I found this thread: http://lkml.org/lkml/2007/4/1/237 > > I guess the complete patch was never finished? I could sure it (for > pretty much the same reason as lguest). It was, but untested (widely). The (google) search

Re: mkasm-offsets.sh ?

On Dec 4, 2007 9:59 PM, Hollis Blanchard [EMAIL PROTECTED] wrote: Hi, I found this thread: http://lkml.org/lkml/2007/4/1/237 I guess the complete patch was never finished? I could sure it (for pretty much the same reason as lguest). It was, but untested (widely). The (google) search keyword

Re: 2.6.24-rc1-82798a1 compile failure (x86_64)

= 11/4/07 = > > > > I also have CFLAGS set on some computers in my environments since for > > > > packages using GNU autoconf that's the correct way to set the compiler > > > > flags. [] > > ... > > > At minimum the extra CFLAGS needs to be put into the .config - but > > > that's not a too nice

Re: 2.6.24-rc1-82798a1 compile failure (x86_64)

= 11/4/07 = I also have CFLAGS set on some computers in my environments since for packages using GNU autoconf that's the correct way to set the compiler flags. [] ... At minimum the extra CFLAGS needs to be put into the .config - but that's not a too nice solution either. A

Redesigning file2alias for easy merging (bits of kbuild/kconfig)

* Thu, 11 Oct 2007 21:03:14 -0700 (PDT) > On Thu, 11 Oct 2007, Greg KH wrote: > >> On Thu, Oct 11, 2007 at 07:58:04PM -0700, Linus Torvalds wrote: >> > >> > So I merged it all, and I don't expect any problems, but I'm hoping >> > somebody is thinking about that mod_devicetable.h/file2alias.c

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

Hi, Bill. Fri, Oct 12, 2007 at 09:16:01AM -0400: [] > >Coloring isn't useful. If it was, it would be implemented ~16 years ago. > > So anything that wasn't implemented a decade ago is not useful? Virtual > machines, software raid, fair scheduling, jumbo packets, SMT/SMP/NUMA > support, support

Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage

Hi, Bill. Fri, Oct 12, 2007 at 09:16:01AM -0400: [] Coloring isn't useful. If it was, it would be implemented ~16 years ago. So anything that wasn't implemented a decade ago is not useful? Virtual machines, software raid, fair scheduling, jumbo packets, SMT/SMP/NUMA support, support for

Redesigning file2alias for easy merging (bits of kbuild/kconfig)

* Thu, 11 Oct 2007 21:03:14 -0700 (PDT) On Thu, 11 Oct 2007, Greg KH wrote: On Thu, Oct 11, 2007 at 07:58:04PM -0700, Linus Torvalds wrote: So I merged it all, and I don't expect any problems, but I'm hoping somebody is thinking about that mod_devicetable.h/file2alias.c mess. I'm

Re: coding for optimizations (Re: [PATCH 1/2] i386: mce cleanup part1: functional change)

On Thu, Oct 11, 2007 at 05:21:30PM +0200, Adrian Bunk wrote: > On Thu, Oct 11, 2007 at 05:26:09PM +0200, Oleg Verych wrote: > > On Thu, Oct 11, 2007 at 01:14:29AM +0200, Adrian Bunk wrote: > > [] > > > It's also a quite ill idea to think about whether gcc might produce

Re: coding for optimizations (Re: [PATCH 1/2] i386: mce cleanup part1: functional change)

On Thu, Oct 11, 2007 at 01:14:29AM +0200, Adrian Bunk wrote: [] > It's also a quite ill idea to think about whether gcc might produce a > few bytes more or less code at the if when there's such a long printk() > in the middle... printk() problem was discussed with proper banana userspace

Re: coding for optimizations (Re: [PATCH 1/2] i386: mce cleanup part1: functional change)

On Thu, Oct 11, 2007 at 01:14:29AM +0200, Adrian Bunk wrote: [] It's also a quite ill idea to think about whether gcc might produce a few bytes more or less code at the if when there's such a long printk() in the middle... printk() problem was discussed with proper banana userspace

Re: coding for optimizations (Re: [PATCH 1/2] i386: mce cleanup part1: functional change)

On Thu, Oct 11, 2007 at 05:21:30PM +0200, Adrian Bunk wrote: On Thu, Oct 11, 2007 at 05:26:09PM +0200, Oleg Verych wrote: On Thu, Oct 11, 2007 at 01:14:29AM +0200, Adrian Bunk wrote: [] It's also a quite ill idea to think about whether gcc might produce a few bytes more or less code

Re: [PATCH 1/2] i386: mce cleanup part1: functional change

On Tue, Oct 09, 2007 at 04:46:46PM -0400, [EMAIL PROTECTED] wrote: > On Tue, 09 Oct 2007 18:32:30 +0200, Oleg Verych said: > > On Tue, Oct 09, 2007 at 06:06:05PM +0200, Joerg Roedel wrote: > > > > cpu_has() returns int, > > > > but would it

coding for optimizations (Re: [PATCH 1/2] i386: mce cleanup part1: functional change)

On Tue, Oct 09, 2007 at 06:06:05PM +0200, Joerg Roedel wrote: > > > void mcheck_init(struct cpuinfo_x86 *c) > > > { > > > + uint32_t mca, mce; > > > + > > > if (mce_disabled==1) > > > return; > > > > > > + mca = cpu_has(c, X86_FEATURE_MCA); > > > + mce = cpu_has(c,

Re: [PATCH 1/2] i386: mce cleanup part1: functional change

On Tue, Oct 09, 2007 at 06:06:05PM +0200, Joerg Roedel wrote: > > cpu_has() returns int, > > but would it be better to have something like > > > > if (!mce_disabled && > > !(c->x86_capability & (X86_FEATURE_MCA | X86_FEATURE_MCE)) { > > printk(KERN_INFO "CPU%i: No machine

Re: [PATCH 1/2] i386: mce cleanup part1: functional change

* Tue, 9 Oct 2007 14:49:55 +0200 [] > @@ -33,9 +33,20 @@ void fastcall (*machine_check_vector)(struct pt_regs *, > long error_code) = unexp > /* This has to be run for each processor */ > void mcheck_init(struct cpuinfo_x86 *c) > { > + uint32_t mca, mce; > + > if (mce_disabled==1)

Re: [PATCH -mm -v4 1/3] i386/x86_64 boot: setup data

* Tue, 09 Oct 2007 16:55:23 +0800 > > On Tue, 2007-10-09 at 02:06 +1000, Nick Piggin wrote: >> On Tuesday 09 October 2007 18:22, Huang, Ying wrote: [] >> I'm just wondering whether you really need to access highmem in >> boot code... > > Because the zero page (boot_parameters) of i386 boot

Re: [RFC/RFT] kbuild: save ARCH & CROSS_COMPILE

On Tue, Oct 09, 2007 at 06:17:43AM +0200, Sam Ravnborg wrote: > > > > What about, that this is the first ever prompt, that must be shown and > > written to the .config? > Two issues to fix before we can do this: > 1) chocie values cannot have more than one prompt what occupying all my time now

Re: [RFC/RFT] kbuild: save ARCH CROSS_COMPILE

On Tue, Oct 09, 2007 at 06:17:43AM +0200, Sam Ravnborg wrote: What about, that this is the first ever prompt, that must be shown and written to the .config? Two issues to fix before we can do this: 1) chocie values cannot have more than one prompt what occupying all my time now is to try

Re: [PATCH -mm -v4 1/3] i386/x86_64 boot: setup data

* Tue, 09 Oct 2007 16:55:23 +0800 On Tue, 2007-10-09 at 02:06 +1000, Nick Piggin wrote: On Tuesday 09 October 2007 18:22, Huang, Ying wrote: [] I'm just wondering whether you really need to access highmem in boot code... Because the zero page (boot_parameters) of i386 boot protocol has 4k

Re: [PATCH 1/2] i386: mce cleanup part1: functional change

* Tue, 9 Oct 2007 14:49:55 +0200 [] @@ -33,9 +33,20 @@ void fastcall (*machine_check_vector)(struct pt_regs *, long error_code) = unexp /* This has to be run for each processor */ void mcheck_init(struct cpuinfo_x86 *c) { + uint32_t mca, mce; + if (mce_disabled==1)

Re: [PATCH 1/2] i386: mce cleanup part1: functional change

On Tue, Oct 09, 2007 at 06:06:05PM +0200, Joerg Roedel wrote: cpu_has() returns int, but would it be better to have something like if (!mce_disabled !(c-x86_capability (X86_FEATURE_MCA | X86_FEATURE_MCE)) { printk(KERN_INFO CPU%i: No machine check support

coding for optimizations (Re: [PATCH 1/2] i386: mce cleanup part1: functional change)

On Tue, Oct 09, 2007 at 06:06:05PM +0200, Joerg Roedel wrote: void mcheck_init(struct cpuinfo_x86 *c) { + uint32_t mca, mce; + if (mce_disabled==1) return; + mca = cpu_has(c, X86_FEATURE_MCA); + mce = cpu_has(c, X86_FEATURE_MCE); + + if (!mca ||

Re: [PATCH 1/2] i386: mce cleanup part1: functional change

On Tue, Oct 09, 2007 at 04:46:46PM -0400, [EMAIL PROTECTED] wrote: On Tue, 09 Oct 2007 18:32:30 +0200, Oleg Verych said: On Tue, Oct 09, 2007 at 06:06:05PM +0200, Joerg Roedel wrote: cpu_has() returns int, but would it be better to have something like if (!mce_disabled

Re: RFC: reviewer's statement of oversight

* Mon, 8 Oct 2007 17:38:52 -0400 > > On Mon, Oct 08, 2007 at 01:33:38PM -0700, H. Peter Anvin wrote: >> Uhm, no. There is no reason an "unimportant" person couldn't review a >> patch, and therefore perform a potentially highly valuable service to >> the maintainer. >> >> None of these are

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

On Mon, Oct 08, 2007 at 10:22:01PM +0200, Sam Ravnborg wrote: > > > > And there's no working alternative to build/config > > system. Thus, let me have my try OK? Thanks! > > I would prefer if you used your time to do small incrmental improvements > to what we have today rather then rewriting

Re: [RFC/RFT] kbuild: save ARCH & CROSS_COMPILE

On Mon, Oct 08, 2007 at 10:02:55PM +0200, Sam Ravnborg wrote: > One of the complaints that I continue to hear is that kbuild > is lacking a way to 'remember' the ARCH and CROSS_COMPILE > values originally used. Yea, finally. What about, that this is the first ever prompt, that must be shown and

initramfs: coloring in userspace, "[PATCH 0/2] Colored kernel output (run2)"

On Mon, Oct 08, 2007 at 05:23:05AM +0200, Willy Tarreau wrote: > On Sun, Oct 07, 2007 at 09:47:25PM +0200, Oleg Verych wrote: > > > For instance, anyone who has experienced read errors on and IDE disk > > > knows that it can literally take hours/days to boot, after displ

initramfs: coloring in userspace, [PATCH 0/2] Colored kernel output (run2)

On Mon, Oct 08, 2007 at 05:23:05AM +0200, Willy Tarreau wrote: On Sun, Oct 07, 2007 at 09:47:25PM +0200, Oleg Verych wrote: For instance, anyone who has experienced read errors on and IDE disk knows that it can literally take hours/days to boot, after displaying thousands of messages

Re: [RFC/RFT] kbuild: save ARCH CROSS_COMPILE

On Mon, Oct 08, 2007 at 10:02:55PM +0200, Sam Ravnborg wrote: One of the complaints that I continue to hear is that kbuild is lacking a way to 'remember' the ARCH and CROSS_COMPILE values originally used. Yea, finally. What about, that this is the first ever prompt, that must be shown and

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

On Mon, Oct 08, 2007 at 10:22:01PM +0200, Sam Ravnborg wrote: And there's no working alternative to build/config system. Thus, let me have my try OK? Thanks! I would prefer if you used your time to do small incrmental improvements to what we have today rather then rewriting from

Re: RFC: reviewer's statement of oversight

* Mon, 8 Oct 2007 17:38:52 -0400 On Mon, Oct 08, 2007 at 01:33:38PM -0700, H. Peter Anvin wrote: Uhm, no. There is no reason an unimportant person couldn't review a patch, and therefore perform a potentially highly valuable service to the maintainer. None of these are indicative of the

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

On Mon, Oct 08, 2007 at 01:01:33AM +0200, Jan Engelhardt wrote: > > On Oct 8 2007 01:02, Oleg Verych wrote: > > > >If you are not going to see OOPes of new kernels running old distros, ask > >any perl hacker (as they lovely mentioned in lkml) to hack for you > >so

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

On Sun, Oct 07, 2007 at 11:11:54PM +0200, Ingo Molnar wrote: > > * Willy Tarreau <[EMAIL PROTECTED]> wrote: > > > I would say that while I'm not particularly fond of flashy colors > > everywhere, I think that being able to use colors to indicate > > particular actions in progress or conditions

Re: syntax highlighting, emacs ([PATCH 0/2] Colored kernel output (run2))

On Sun, Oct 07, 2007 at 10:43:46PM +0200, Jan Engelhardt wrote: > > On Oct 7 2007 22:50, Oleg Verych wrote: > > > >In fact mc config (ini) section is a better way. > > Yes, for the default colors. But /usr/share/mc/syntax/ specifies > more of them. Syntax highlightin

tty UI (Re: [PATCH 0/2] Colored kernel output (run2))

On Sun, Oct 07, 2007 at 10:04:44PM +0200, Jan Engelhardt wrote: > > On Oct 7 2007 22:00, Rene Herman wrote: > > On 10/07/2007 09:56 PM, Jan Engelhardt wrote: > > > >> Some is good, as long as it is not excessive. While I could imagine that > >> Knoppix will abuse the feature and use

Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

On Sun, Oct 07, 2007 at 09:13:09PM +0200, Willy Tarreau wrote: > On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: > > On 10/07/2007 06:12 PM, Ingo Molnar wrote: > > > > >* Oleg Verych <[EMAIL PROTECTED]> wrote: > > > > >>Coloring isn'

"Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"

Hallo, Ingo. On Sun, Oct 07, 2007 at 08:07:07AM +0200, Ingo Molnar wrote: > > * Oleg Verych <[EMAIL PROTECTED]> wrote: > > > > > * completely useless, if properly implemented in userspace (with > > > > much reacher functionality). > > > >

Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage

Hallo, Ingo. On Sun, Oct 07, 2007 at 08:07:07AM +0200, Ingo Molnar wrote: * Oleg Verych [EMAIL PROTECTED] wrote: * completely useless, if properly implemented in userspace (with much reacher functionality). that's hogwash. No user-space runs during early bootup. (and yes i

Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage

On Sun, Oct 07, 2007 at 09:13:09PM +0200, Willy Tarreau wrote: On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: On 10/07/2007 06:12 PM, Ingo Molnar wrote: * Oleg Verych [EMAIL PROTECTED] wrote: Coloring isn't useful. If it was, it would be implemented ~16 years ago

tty UI (Re: [PATCH 0/2] Colored kernel output (run2))

On Sun, Oct 07, 2007 at 10:04:44PM +0200, Jan Engelhardt wrote: On Oct 7 2007 22:00, Rene Herman wrote: On 10/07/2007 09:56 PM, Jan Engelhardt wrote: Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use

Re: syntax highlighting, emacs ([PATCH 0/2] Colored kernel output (run2))

On Sun, Oct 07, 2007 at 10:43:46PM +0200, Jan Engelhardt wrote: On Oct 7 2007 22:50, Oleg Verych wrote: In fact mc config (ini) section is a better way. Yes, for the default colors. But /usr/share/mc/syntax/ specifies more of them. Syntax highlighting, OK. Kind of funny thing

Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage

On Sun, Oct 07, 2007 at 11:11:54PM +0200, Ingo Molnar wrote: * Willy Tarreau [EMAIL PROTECTED] wrote: I would say that while I'm not particularly fond of flashy colors everywhere, I think that being able to use colors to indicate particular actions in progress or conditions can be a

Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage

On Mon, Oct 08, 2007 at 01:01:33AM +0200, Jan Engelhardt wrote: On Oct 8 2007 01:02, Oleg Verych wrote: If you are not going to see OOPes of new kernels running old distros, ask any perl hacker (as they lovely mentioned in lkml) to hack for you something like: sed -u -e ' /^1/s_

Re: On text size and run time if config is "n", [PATCH 2/2] Colored kernel output (run3)

On Sat, Oct 06, 2007 at 11:27:54PM +0200, Jan Engelhardt wrote: [] > _call_console_drivers() skips the substring and passes on the rest of the > message: > > if (msg_level < 0 && ((end - cur_index) > 2) && > LOG_BUF(cur_index + 0) == '<' && >

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

On Sat, Oct 06, 2007 at 11:10:48PM +0200, Sam Ravnborg wrote: > On Sat, Oct 06, 2007 at 10:47:21PM +0200, Oleg Verych wrote: > > On Sat, Oct 06, 2007 at 08:59:20PM +0200, Sam Ravnborg wrote: > > > > Maintenance and acceptance of the m4/make/perl/C/ncurses community of my >

About summary in the subject (Re: [PATCH 0/2] Colored kernel output (run2))

On Sat, Oct 06, 2007 at 11:03:38PM +0200, Jan Engelhardt wrote: > > On Oct 6 2007 23:03, Oleg Verych wrote: > >> > >> (btw., i corrected the subject line to remove the 'NAK'. Why do you > >> think you can 'NAK' a patch in this field?) > > > >I

Re: [PATCH 2/2] Colored kernel output (run3)

Thanks for dealing with my acidness in the first patch :) But what about this one? On Sat, Oct 06, 2007 at 10:10:01PM +0200, Jan Engelhardt wrote: > > Colored kernel message output (2/2) > > By popular request, this patch adds per-loglevel coloring. > The user may set values using

Re: [PATCH 0/2] Colored kernel output (run2)

robust functionality that i personally welcome. The > default is not changed in any way. > > (btw., i corrected the subject line to remove the 'NAK'. Why do you > think you can 'NAK' a patch in this field?) I added comment (like this), so anyone can skip reading body, if headers

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

On Sat, Oct 06, 2007 at 08:59:20PM +0200, Sam Ravnborg wrote: > > Maintenance and acceptance of the m4/make/perl/C/ncurses community of my > > mainly `TERM=linux ; sed && sh' approach is more important for me. > > There is noone having trouble with ncurses dependency today. Who wants to meet a

Re: [PATCH] Cute feature: colored printk output

* Sat, 6 Oct 2007 13:08:35 +0200 > * Jan Engelhardt <[EMAIL PROTECTED]> wrote: > >> Colored kernel message output >> >> Let's work more on Linux's cuteness! >> [http://lkml.org/lkml/2007/10/4/431] The following patch makes it >> possible to give kernel messages a selectable color Only boot

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

On Sat, Oct 06, 2007 at 09:03:00AM -0700, Linus Torvalds wrote: > > > On Sat, 6 Oct 2007, Oleg Verych wrote: > > > > Thanks. I will be specific, after i will finish, what i already have, > > to make air a bit less hot. Of course everything will be back > > comp

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

On Fri, Oct 05, 2007 at 04:35:41AM +0200, Roman Zippel wrote: > Hi, > > On Mon, 1 Oct 2007, Oleg Verych wrote: > > > Today's kconfig was proposed and accepted in a very unpleasant > > circumstances, has very poor design, development and no working > > alternative (

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

On Fri, Oct 05, 2007 at 04:35:41AM +0200, Roman Zippel wrote: Hi, On Mon, 1 Oct 2007, Oleg Verych wrote: Today's kconfig was proposed and accepted in a very unpleasant circumstances, has very poor design, development and no working alternative (for 5+ years now). If you want to make

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

On Sat, Oct 06, 2007 at 09:03:00AM -0700, Linus Torvalds wrote: On Sat, 6 Oct 2007, Oleg Verych wrote: Thanks. I will be specific, after i will finish, what i already have, to make air a bit less hot. Of course everything will be back compatible, so nothing to worry about

Re: [PATCH] Cute feature: colored printk output

* Sat, 6 Oct 2007 13:08:35 +0200 * Jan Engelhardt [EMAIL PROTECTED] wrote: Colored kernel message output Let's work more on Linux's cuteness! [http://lkml.org/lkml/2007/10/4/431] The following patch makes it possible to give kernel messages a selectable color Only boot time selectable?

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

On Sat, Oct 06, 2007 at 08:59:20PM +0200, Sam Ravnborg wrote: Maintenance and acceptance of the m4/make/perl/C/ncurses community of my mainly `TERM=linux ; sed sh' approach is more important for me. There is noone having trouble with ncurses dependency today. Who wants to meet a zombie

Re: [PATCH 0/2] Colored kernel output (run2)

the subject line to remove the 'NAK'. Why do you think you can 'NAK' a patch in this field?) I added comment (like this), so anyone can skip reading body, if headers are Oleg Verych NAK. In case if `NAK' have a magic meaning in the LKML, like control characters in the tty, i'm sorry. But how

Re: [PATCH 2/2] Colored kernel output (run3)

Thanks for dealing with my acidness in the first patch :) But what about this one? On Sat, Oct 06, 2007 at 10:10:01PM +0200, Jan Engelhardt wrote: Colored kernel message output (2/2) By popular request, this patch adds per-loglevel coloring. The user may set values using vt.printk_color=

About summary in the subject (Re: [PATCH 0/2] Colored kernel output (run2))

On Sat, Oct 06, 2007 at 11:03:38PM +0200, Jan Engelhardt wrote: On Oct 6 2007 23:03, Oleg Verych wrote: (btw., i corrected the subject line to remove the 'NAK'. Why do you think you can 'NAK' a patch in this field?) I added comment (like this), so anyone can skip reading body

Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

On Sat, Oct 06, 2007 at 11:10:48PM +0200, Sam Ravnborg wrote: On Sat, Oct 06, 2007 at 10:47:21PM +0200, Oleg Verych wrote: On Sat, Oct 06, 2007 at 08:59:20PM +0200, Sam Ravnborg wrote: Maintenance and acceptance of the m4/make/perl/C/ncurses community of my mainly `TERM=linux ; sed sh

Re: On text size and run time if config is n, [PATCH 2/2] Colored kernel output (run3)

On Sat, Oct 06, 2007 at 11:27:54PM +0200, Jan Engelhardt wrote: [] _call_console_drivers() skips the N substring and passes on the rest of the message: if (msg_level 0 ((end - cur_index) 2) LOG_BUF(cur_index + 0) == ''

A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

* Fri, 28 Sep 2007 11:12:51 -0600 > On Thursday 27 September 2007, Nick Piggin wrote: >> On Saturday 29 September 2007 00:34, Linus Torvalds wrote: >> > On Fri, 28 Sep 2007, Nick Piggin wrote: >> > > > God I hate select. >> > > >> > > IMO a better implementation would result in a notification /

A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)

* Fri, 28 Sep 2007 11:12:51 -0600 On Thursday 27 September 2007, Nick Piggin wrote: On Saturday 29 September 2007 00:34, Linus Torvalds wrote: On Fri, 28 Sep 2007, Nick Piggin wrote: God I hate select. IMO a better implementation would result in a notification / confirmation of

reviewed (Re: [patch 1/7] Extended crashkernel command line)

Wed, Sep 26, 2007 at 11:05:33PM +0200, Bernhard Walle: > * Oleg Verych <[EMAIL PROTECTED]> [2007-09-26 20:18]: > > > > > > --- a/kernel/kexec.c > > > +++ b/kernel/kexec.c > > > @@ -1172,33 +1172,50 @@ static int __init parse_crashkernel_mem( > >

why network devices don't do reference counting? (Re: [PATCH] Module use count must be updated as bridges are created/destroyed)

* Wed, 26 Sep 2007 08:37:05 -0700 * Organization: Linux Foundation > > On Wed, 26 Sep 2007 08:53:27 +0100 > "Jan Beulich" <[EMAIL PROTECTED]> wrote: > >> Otherwise 'modprobe -r' on a module having a dependency on bridge will >> implicitly unload bridge, bringing down all connectivity that was >>

Re: [patch 1/7] Extended crashkernel command line

Wed, Sep 26, 2007 at 06:16:02PM +0200, Bernhard Walle (part two, see bottom): > > memparse(), as a wrapper for somple_strtoll(), always have a return value > > (zero by default). > > Sorry for my typos, i should write `simple_strtoull()'. This

Re: [patch 1/7] Extended crashkernel command line

Wed, Sep 26, 2007 at 06:16:02PM +0200, Bernhard Walle (part two, see bottom): memparse(), as a wrapper for somple_strtoll(), always have a return value (zero by default). http://article.gmane.org/gmane.linux.kernel/583426 Sorry for my typos, i should write `simple_strtoull()'. This function

why network devices don't do reference counting? (Re: [PATCH] Module use count must be updated as bridges are created/destroyed)

* Wed, 26 Sep 2007 08:37:05 -0700 * Organization: Linux Foundation On Wed, 26 Sep 2007 08:53:27 +0100 Jan Beulich [EMAIL PROTECTED] wrote: Otherwise 'modprobe -r' on a module having a dependency on bridge will implicitly unload bridge, bringing down all connectivity that was using bridges.

reviewed (Re: [patch 1/7] Extended crashkernel command line)

Wed, Sep 26, 2007 at 11:05:33PM +0200, Bernhard Walle: * Oleg Verych [EMAIL PROTECTED] [2007-09-26 20:18]: --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -1172,33 +1172,50 @@ static int __init parse_crashkernel_mem( do { unsigned long long start = 0, end = ULLONG_MAX

Re: [patch 3/5] Add samples subdir

* Tue, 25 Sep 2007 21:00:36 +0200 > > Hi Mathieu & Randy. > > On Tue, Sep 25, 2007 at 08:11:48AM -0400, Mathieu Desnoyers wrote: >> From: Randy Dunlap <[EMAIL PROTECTED]> >> >> Begin infrastructure for kernel code samples in the samples/ directory. >> Add its Kconfig and Kbuild files. >> Source

Re: [patch 1/7] Extended crashkernel command line

* Tue, 25 Sep 2007 20:22:58 +0200 > > This is the generic part of the patch. It adds a parse_crashkernel() function > in kernel/kexec.c that is called by the architecture specific code that > actually reserves the memory. That function takes the whole command line and > looks itself for

Re: [patch 1/7] Extended crashkernel command line

* Tue, 25 Sep 2007 20:22:58 +0200 This is the generic part of the patch. It adds a parse_crashkernel() function in kernel/kexec.c that is called by the architecture specific code that actually reserves the memory. That function takes the whole command line and looks itself for crashkernel= in

Re: [patch 3/5] Add samples subdir

* Tue, 25 Sep 2007 21:00:36 +0200 Hi Mathieu Randy. On Tue, Sep 25, 2007 at 08:11:48AM -0400, Mathieu Desnoyers wrote: From: Randy Dunlap [EMAIL PROTECTED] Begin infrastructure for kernel code samples in the samples/ directory. Add its Kconfig and Kbuild files. Source its Kconfig file

Re: 2.6.23-rc7 + radeonfb/s2ram

* Sun, 23 Sep 2007 22:22:28 +0300 * Organization: Home [] >> > >> > So there, if one wants "ATI Radeon display support" on Radeon XPRESS >> > 200M with >> > X using radeon_drv.so, *should* put "Framebuffer Console support" to N >> > (if it's >> > not already). [] > Bottom line: no

Re: [patch 1/7] Extended crashkernel command line

On Sun, Sep 23, 2007 at 10:19:43PM +0200, Bernhard Walle wrote: [] > > +int __init get_crashkernel_params(u64 *memsize, u64 *addrbase, char > > *cmdline, u64 ram); > > Andrew, what's your opinion on this? Whould I resend the patch with > shorter type names? Also, maybe it will be better to

Re: [PATCH][RFC] Extend "memparse" to allow a NULL return pointer value.

* Sat, 15 Sep 2007 12:27:07 -0400 (EDT) > Extend the memparse() routine to allow a caller to use NULL as the > second parameter value if he has no interest in that returned value. (not `he', but `it', even if `he', then better `callers' + `they') > --- > > there appear to be quite a number of

Re: Unfortunate infinite make recursion

On Sun, Sep 23, 2007 at 08:03:35AM +0200, Sam Ravnborg wrote: > > > Please Oleg. > > > You know very well that most people will not have their kernel src RO. > > > > Sure, if it will be not comfortable. > > > > But if kbuild deals with this transparently, it must be OK. Brokenness > > due to

  1   2   3   4   5   6   7   >