Re: [PATCH] Compress kernel modules on installation.

[Oleg Verych]

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. 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)
>  >
>  > And what if i like bzip2 (yea sometimes better) or 7zip (better if 
> !EMBEDDED)
>  > or whatever?
>  >
>  > It's pure user/distro question.
>
>  not exactly, as only gzip is supported by module-init-tools. However,
>  if you come up with a patch to implement lzma or equivalent for
>  module-init-tools, it may be useful.

Oh, come on! It's userspace, i have scripts managing existence/compression
on per-file basis on my comp. If most distros just drop thousands of useless
(sometimes compressed) stuff to your harddisk, it's not kernel's or
modules-init-tools'
problem.

Also having compressed over compressed stuff, like on initramfs booting image
with such modules (if by defaults) may cause bigger file, more CPU overhead.

It is userspace and all that policy stuff, etc., etc.

Want to make a minidistro on lkml? Well, i see klibc working fine already.
___
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Compress kernel modules on installation.

[Oleg Verych]

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)

And what if i like bzip2 (yea sometimes better) or 7zip (better if !EMBEDDED)
or whatever?

It's pure user/distro question.
___
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Compress kernel modules on installation.

[Oleg Verych]

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)

And what if i like bzip2 (yea sometimes better) or 7zip (better if !EMBEDDED)
or whatever?

It's pure user/distro question.
___
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Compress kernel modules on installation.

[Oleg Verych]

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. 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)
  
   And what if i like bzip2 (yea sometimes better) or 7zip (better if 
 !EMBEDDED)
   or whatever?
  
   It's pure user/distro question.

  not exactly, as only gzip is supported by module-init-tools. However,
  if you come up with a patch to implement lzma or equivalent for
  module-init-tools, it may be useful.

Oh, come on! It's userspace, i have scripts managing existence/compression
on per-file basis on my comp. If most distros just drop thousands of useless
(sometimes compressed) stuff to your harddisk, it's not kernel's or
modules-init-tools'
problem.

Also having compressed over compressed stuff, like on initramfs booting image
with such modules (if by defaults) may cause bigger file, more CPU overhead.

It is userspace and all that policy stuff, etc., etc.

Want to make a minidistro on lkml? Well, i see klibc working fine already.
___
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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/null redirection anywhere here

And here comes "no comments" part.
__
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 filechk
> >   $(Q)set -e; \
> > - $($(quiet)chk_filechk); \
> > + echo $($(quiet)chk_filechk);\
> >   mkdir -p $(dir $@); \
> >   $(filechk_$(1)) < $< > [EMAIL PROTECTED];  \
> >   if [ -r $@ ] && cmp -s $@ [EMAIL PROTECTED]; then  \
> >   rm -f [EMAIL PROTECTED];   \
> >   else\
> > - $($(quiet)upd_filechk); \
> > + echo $($(quiet)upd_filechk);\
> >   mv -f [EMAIL PROTECTED] $@;\
> >   fi
> >  endef
> 
> 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".

> nor does it give the same behavior ... your propposed change will echo
> blank lines in the silent mode which is incorrect.

At least this will not crash, if you don't have some variable set.

Efficiency there is lesser number of variables(-2 vs +2), that are copied
for every make job, and are textually parsed and searched.

> it also does not seem to follow the standard convention of other
> kconfig commands that have quiet/silent prefixes ... such commands do
> not define arguments to an unknown program/function, nor do they add
> arbitrary redirection which gets leads to confusion as to final
> expansion, they define the entire command.

Right. Seems like you are talking about "[quite_]cmd_*", which are
commands. Here you've invented such rules for ordinary utility in
`filechk`. And by try they've failed due to mixing functionality
dependency on having arbitrary variable being set.

Shell syntax tried to avoid this, but `make` syntax and ``convention''
did a boom. Boom, where hacker's V=1 mode failed itself and failed to
give a clue about problem (at least, when i saw Sam's message in
linux-kbuild). Yea, `make` is not needed.

> what Sam posted (and what was merged) makes sense to me.
> -mike
> 
-- 
-o--=O`C
 #oo'L O
<___=E M
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 tree.
> > >
> > > See updated patch below.
> > >
> > >   Sam
> > 
> > Sam, do you agree my fix was more reliable (yea, not only efficient:)?
> You more or less just reverted the original patch - so it was obviously
> more reliable than introducing new stuff as the fix did.
> But we are at -r1 so I prefer to get the inteded behaviour
> and not the minmal fix.

Processing below changes arguments, not semantics of generated shell
code. And IMHO this is more reliable way of doing things. If one really
wants silence without commonly accepted ">/dev/null 2>&1" practice, then
choose portable "-n" argument for `echo`.

- 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 filechk
$(Q)set -e; \
-   $($(quiet)chk_filechk); \
+   echo $($(quiet)chk_filechk);\
mkdir -p $(dir $@); \
$(filechk_$(1)) < $< > [EMAIL PROTECTED];   \
if [ -r $@ ] && cmp -s $@ [EMAIL PROTECTED]; then   \
rm -f [EMAIL PROTECTED];\
else\
-   $($(quiet)upd_filechk); \
+   echo $($(quiet)upd_filechk);\
mv -f [EMAIL PROTECTED] $@; \
fi
 endef
__
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 tree.
  
   See updated patch below.
  
 Sam
  
  Sam, do you agree my fix was more reliable (yea, not only efficient:)?
 You more or less just reverted the original patch - so it was obviously
 more reliable than introducing new stuff as the fix did.
 But we are at -r1 so I prefer to get the inteded behaviour
 and not the minmal fix.

Processing below changes arguments, not semantics of generated shell
code. And IMHO this is more reliable way of doing things. If one really
wants silence without commonly accepted /dev/null 21 practice, then
choose portable -n argument for `echo`.

- 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 filechk
$(Q)set -e; \
-   $($(quiet)chk_filechk); \
+   echo $($(quiet)chk_filechk);\
mkdir -p $(dir $@); \
$(filechk_$(1))  $  [EMAIL PROTECTED];   \
if [ -r $@ ]  cmp -s $@ [EMAIL PROTECTED]; then   \
rm -f [EMAIL PROTECTED];\
else\
-   $($(quiet)upd_filechk); \
+   echo $($(quiet)upd_filechk);\
mv -f [EMAIL PROTECTED] $@; \
fi
 endef
__
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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/null redirection anywhere here

And here comes no comments part.
__
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 filechk
$(Q)set -e; \
  - $($(quiet)chk_filechk); \
  + echo $($(quiet)chk_filechk);\
mkdir -p $(dir $@); \
$(filechk_$(1))  $  [EMAIL PROTECTED];  \
if [ -r $@ ]  cmp -s $@ [EMAIL PROTECTED]; then  \
rm -f [EMAIL PROTECTED];   \
else\
  - $($(quiet)upd_filechk); \
  + echo $($(quiet)upd_filechk);\
mv -f [EMAIL PROTECTED] $@;\
fi
   endef
 
 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.

 nor does it give the same behavior ... your propposed change will echo
 blank lines in the silent mode which is incorrect.

At least this will not crash, if you don't have some variable set.

Efficiency there is lesser number of variables(-2 vs +2), that are copied
for every make job, and are textually parsed and searched.

 it also does not seem to follow the standard convention of other
 kconfig commands that have quiet/silent prefixes ... such commands do
 not define arguments to an unknown program/function, nor do they add
 arbitrary redirection which gets leads to confusion as to final
 expansion, they define the entire command.

Right. Seems like you are talking about [quite_]cmd_*, which are
commands. Here you've invented such rules for ordinary utility in
`filechk`. And by try they've failed due to mixing functionality
dependency on having arbitrary variable being set.

Shell syntax tried to avoid this, but `make` syntax and ``convention''
did a boom. Boom, where hacker's V=1 mode failed itself and failed to
give a clue about problem (at least, when i saw Sam's message in
linux-kbuild). Yea, `make` is not needed.

 what Sam posted (and what was merged) makes sense to me.
 -mike
 
-- 
-o--=O`C
 #oo'L O
___=E M
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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 new line in silent mode, one gets working "V=1" (and
all others).
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

>> 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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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 new line in silent mode, one gets working V=1 (and
all others).
_
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

 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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: translations (Re: Kbuild update)

[Oleg Verych]

@ 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..."
> >http://www.google.com/translate?u=http%3A%2F%2Flxr.linux.no%2Flinux%2FDocumentation%2FHOWTO=en%7Czh-TW=en=UTF8
> >?
> >
> >In case if people will help Google to have better quality of translation,
> >that will be better generally for much bigger number of *people*,
> >especially in China, isn't it?
> 
> Perhaps yes.
> 
> But at least now, that kind of translation still sucks. It can
> satisfy me.
> 
> >
> >Making any official world-domination/new-world-order projects with
> >Linux will not help IMHO. Very fast code flow and almost no up to date
> >documentation is still relevant and google search + email archives
> >are not going to be obsolete in the near future.
> >
> >Also, future of the linux codebase with Chinese comments in C or in
> >ASM is kind of wired nightmare. Those, who cannot read actual source
> >code (i.e. C) will not go too far.
> >
> >So, translation guys, maybe you will stop making noise and will start
> >to make e.g. less buggy Linux? Greg KH have much more stuff to care,
> >than some translations IMHO.
> 
> I never say to translate C comments. What we want to translate is the
> strings in Kconfig.

ftp://flower.upol.cz/upload/Configure.help

OK, please, take a look at stuff, Korean guys did 5-6 years ago. One
particular ARM port (S3C2410X) along with an ARM bootloader (vivi) was
done. Yet for some reason official Linux port has another developers, and,
it seems, it was done some time (~1-2 years) later.

> I abosutely agree that we should focus on the exsiting bugs of Linux,
> but like Greg's inclusion of some kernel doc translations, this kind
> of work is really helpful to attract some kernel newbies from none
> English-speaking countries. Even we can't make offical efforts,
> the civil work, like TLKTP, is still worthy.
...

> Believe me, I am leading a local LUG in my college and I found that one
> _big_ reason that why the newbies are afraid of Linux kernel is
> English, instead of the C tricks or low-level programming.

IMHO, there is so much stuff done, that any brilliant C or whatever-asm
coder *have* to study at least something of it. And, in order to do a
valuable contribution, one must know the work-flow, people *and* English.
This is usually done by reading mailing list *and* archives for quite
some time. This takes time, this takes effort, but this also have huge
impact on intelligence and culture of the `coders'.

Do you ever have a question about why History exists and is studied on
all levels of education? Same with programming. Without
history-via-English, one have no strong roots, thus base for grow and
flower.

OTOH, Internet has so much noise and crap all over the place, that
information is very hard to find. It takes much time to sort and see it.
Yet, providing noise generating, like in-tree translations, seems, is a
very easy way around (not taking maintaining in account).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: translations (Re: Kbuild update)

[Oleg Verych]

@ 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...
 http://www.google.com/translate?u=http%3A%2F%2Flxr.linux.no%2Flinux%2FDocumentation%2FHOWTOlangpair=en%7Czh-TWhl=enie=UTF8
 ?
 
 In case if people will help Google to have better quality of translation,
 that will be better generally for much bigger number of *people*,
 especially in China, isn't it?
 
 Perhaps yes.
 
 But at least now, that kind of translation still sucks. It can
 satisfy me.
 
 
 Making any official world-domination/new-world-order projects with
 Linux will not help IMHO. Very fast code flow and almost no up to date
 documentation is still relevant and google search + email archives
 are not going to be obsolete in the near future.
 
 Also, future of the linux codebase with Chinese comments in C or in
 ASM is kind of wired nightmare. Those, who cannot read actual source
 code (i.e. C) will not go too far.
 
 So, translation guys, maybe you will stop making noise and will start
 to make e.g. less buggy Linux? Greg KH have much more stuff to care,
 than some translations IMHO.
 
 I never say to translate C comments. What we want to translate is the
 strings in Kconfig.

ftp://flower.upol.cz/upload/Configure.help

OK, please, take a look at stuff, Korean guys did 5-6 years ago. One
particular ARM port (S3C2410X) along with an ARM bootloader (vivi) was
done. Yet for some reason official Linux port has another developers, and,
it seems, it was done some time (~1-2 years) later.

 I abosutely agree that we should focus on the exsiting bugs of Linux,
 but like Greg's inclusion of some kernel doc translations, this kind
 of work is really helpful to attract some kernel newbies from none
 English-speaking countries. Even we can't make offical efforts,
 the civil work, like TLKTP, is still worthy.
...

 Believe me, I am leading a local LUG in my college and I found that one
 _big_ reason that why the newbies are afraid of Linux kernel is
 English, instead of the C tricks or low-level programming.

IMHO, there is so much stuff done, that any brilliant C or whatever-asm
coder *have* to study at least something of it. And, in order to do a
valuable contribution, one must know the work-flow, people *and* English.
This is usually done by reading mailing list *and* archives for quite
some time. This takes time, this takes effort, but this also have huge
impact on intelligence and culture of the `coders'.

Do you ever have a question about why History exists and is studied on
all levels of education? Same with programming. Without
history-via-English, one have no strong roots, thus base for grow and
flower.

OTOH, Internet has so much noise and crap all over the place, that
information is very hard to find. It takes much time to sort and see it.
Yet, providing noise generating, like in-tree translations, seems, is a
very easy way around (not taking maintaining in account).

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

translations (Re: Kbuild update)

[Oleg Verych]

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 languages.
> >> 
> >> One criteria to get a .po file integrated could be at least 10% of the
> >> strings translated or similar.
> 
> Well, I think it's worthy. The translation effort will be valuable
> and much helpful for non-English-speaking peoples.
> 
> >
> >Besides the initial translation efforts a big problem would be to 
> >also find people who will regularly update the translations for
> >many years.
> >
> 
> Yes, that's really a problem. But I think the updates won't be
> too frequent, only update for stable release is enough.
> 
> If we can make this to be an offical project for Linux kernel, I
> think it won't be a big problem.

"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..."
http://www.google.com/translate?u=http%3A%2F%2Flxr.linux.no%2Flinux%2FDocumentation%2FHOWTO=en%7Czh-TW=en=UTF8
?

In case if people will help Google to have better quality of translation,
that will be better generally for much bigger number of *people*,
especially in China, isn't it?

Making any official world-domination/new-world-order projects with
Linux will not help IMHO. Very fast code flow and almost no up to date
documentation is still relevant and google search + email archives
are not going to be obsolete in the near future.

Also, future of the linux codebase with Chinese comments in C or in
ASM is kind of wired nightmare. Those, who cannot read actual source
code (i.e. C) will not go too far.

So, translation guys, maybe you will stop making noise and will start
to make e.g. less buggy Linux? Greg KH have much more stuff to care,
than some translations IMHO.

> Regards.
> 
> 
>  Cong
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

translations (Re: Kbuild update)

[Oleg Verych]

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 languages.
  
  One criteria to get a .po file integrated could be at least 10% of the
  strings translated or similar.
 
 Well, I think it's worthy. The translation effort will be valuable
 and much helpful for non-English-speaking peoples.
 
 
 Besides the initial translation efforts a big problem would be to 
 also find people who will regularly update the translations for
 many years.
 
 
 Yes, that's really a problem. But I think the updates won't be
 too frequent, only update for stable release is enough.
 
 If we can make this to be an offical project for Linux kernel, I
 think it won't be a big problem.

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...
http://www.google.com/translate?u=http%3A%2F%2Flxr.linux.no%2Flinux%2FDocumentation%2FHOWTOlangpair=en%7Czh-TWhl=enie=UTF8
?

In case if people will help Google to have better quality of translation,
that will be better generally for much bigger number of *people*,
especially in China, isn't it?

Making any official world-domination/new-world-order projects with
Linux will not help IMHO. Very fast code flow and almost no up to date
documentation is still relevant and google search + email archives
are not going to be obsolete in the near future.

Also, future of the linux codebase with Chinese comments in C or in
ASM is kind of wired nightmare. Those, who cannot read actual source
code (i.e. C) will not go too far.

So, translation guys, maybe you will stop making noise and will start
to make e.g. less buggy Linux? Greg KH have much more stuff to care,
than some translations IMHO.

 Regards.
 
 
  Cong
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kbuild in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

stuff (Re: Kbuild update)

[Oleg Verych]

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 interface for menuconfig (ala tig, htop and others)
> >>
> >> Sorry.. your comparison {menuconfig, htop} raises an "incompatible
> >> pointer passed" on my side. Please explain :)
> >
> >htop is a nice ncurses based interface to top.
> >
> >Try "F2" and see a nice layout for a menu structure remotely
> >similar to menuconfig.
>
> I cannot really think how htop F2 would even be CLOSE to menuconfig.
> Just that we are talking about the same thing:
> http://jengelh.hopto.org/GFX0/htopf2.png
> hell no, menuconfig looks much nicer than that.
>
> >I could mention a few more - this was more to say that there
> >exist much beter looking ncurses based tools than menuconfig.
>
> hm, I can only think of mc right now.

ncurses is the tty(terminal) independent interface to generic
character-based displaying devices, it has nothing to do with
the ``look'', only stupid legacy and dead stuff.

Borland Turbo Vision has a look, but it was closely
tied to OO model and features of the library. Comparing
Midnight Commander (c) 2007 to Dos Navigator (c) 1997,
i pretty much about to say, that former blow-sucks, even
latter had DOS as an ``OS''.

Going back to ttys. I was very deeply impressed, after i
started to look back in history.

I was searching for shell history shortly after having all
kbuild ideas and historical research done.

In parallel i was thinking about user interface and IDE (even
if it will be not so luzer-friendly, eye-candy as drag-graphical
ones). UI on character-based devices. This is where i hit
another shit in terms of tty layering, tty controlling, user/kernel
space tty drivers and TERM=linux codebase quality/featurity
and userbase(wtf ncurses?).

After in-kernel printk coloring stuff, i was completely upset.

I've found a link about origins of the Almquist Shell (ash).
Kenneth Almquist had alternative not only for proprietary
shell implementations. He also implemented atty -- userlevel
tty, which is, in my opinion, has much bigger potential. All i
need from kernel now is a fast region (with chars/attributes)
filling routine, much like Turbo Vision has.

But nearly 20 years after, BSD, Free Software and Open Source
hypes led userspace to almost nowhere (IMHO). Yes Linus and
Linux are cool, but what else? udev?
Thank you very much!

People, where is you imagination? I know it's hard to have a few
time for Linux, but this doesn't mean one must stop thinking and
asking questions.

Now, what can i do to mc-minded people, having (colored) printk
in non-debugging kernels, managed via udev?

Reach and flexible build system with UI as comfortable as a brush
and easel for painter? No, i'd better do something else...

ftp://flower.upol.cz/dts/Ash/

i did sorted out (a)sh stuff; kbuild ideas, which are much more
complicated and require at least those improvements to the shell,
i did send some time ago with almost no positive reaction.
Now i pretty much sure, why there was such reaction.

BTW, ash had built-in `test` && `expr`, appeared from nothing
today's odd job, where bash GPL routine is copied instead of Linux's
euidaccess() is a... A little surprise!

http://sourceware.org/ml/libc-alpha/2007-01/msg00099.html
`--http://sourceware.org/ml/libc-alpha/2007-01/msg00105.html

With the flexible build system, which can tune everything easily, such
crap form the software whore, couldn't exist. Does shell know, about new
size of the quanta of the pipe in Linux? One must write m4 autoconf crap?..

200X Monty Python: Crap. "Crap, crap crap. Crap? Crap crap!"
http://www.youtube.com/watch?v=wZ7YedEopp4
Or...
http://www.adultswim.com/video/?episodeID=8a25c39214b602990114b8a43a37012b

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Yes, fsck! I AM SUBSCRIBED! AND I KNOW WHAT TO DO IF I WILL
CHANGE MY MIND!
PLEASE CC ME, I DON'T FOLLOW LKML!!
Oh, crap.
-o--=O`C
 #oo'L O
<___=E M
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

stuff (Re: Kbuild update)

[Oleg Verych]

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 interface for menuconfig (ala tig, htop and others)
 
  Sorry.. your comparison {menuconfig, htop} raises an incompatible
  pointer passed on my side. Please explain :)
 
 htop is a nice ncurses based interface to top.
 
 Try F2 and see a nice layout for a menu structure remotely
 similar to menuconfig.

 I cannot really think how htop F2 would even be CLOSE to menuconfig.
 Just that we are talking about the same thing:
 http://jengelh.hopto.org/GFX0/htopf2.png
 hell no, menuconfig looks much nicer than that.

 I could mention a few more - this was more to say that there
 exist much beter looking ncurses based tools than menuconfig.

 hm, I can only think of mc right now.

ncurses is the tty(terminal) independent interface to generic
character-based displaying devices, it has nothing to do with
the ``look'', only stupid legacy and dead stuff.

Borland Turbo Vision has a look, but it was closely
tied to OO model and features of the library. Comparing
Midnight Commander (c) 2007 to Dos Navigator (c) 1997,
i pretty much about to say, that former blow-sucks, even
latter had DOS as an ``OS''.

Going back to ttys. I was very deeply impressed, after i
started to look back in history.

I was searching for shell history shortly after having all
kbuild ideas and historical research done.

In parallel i was thinking about user interface and IDE (even
if it will be not so luzer-friendly, eye-candy as drag-graphical
ones). UI on character-based devices. This is where i hit
another shit in terms of tty layering, tty controlling, user/kernel
space tty drivers and TERM=linux codebase quality/featurity
and userbase(wtf ncurses?).

After in-kernel printk coloring stuff, i was completely upset.

I've found a link about origins of the Almquist Shell (ash).
Kenneth Almquist had alternative not only for proprietary
shell implementations. He also implemented atty -- userlevel
tty, which is, in my opinion, has much bigger potential. All i
need from kernel now is a fast region (with chars/attributes)
filling routine, much like Turbo Vision has.

But nearly 20 years after, BSD, Free Software and Open Source
hypes led userspace to almost nowhere (IMHO). Yes Linus and
Linux are cool, but what else? udev?
Thank you very much!

People, where is you imagination? I know it's hard to have a few
time for Linux, but this doesn't mean one must stop thinking and
asking questions.

Now, what can i do to mc-minded people, having (colored) printk
in non-debugging kernels, managed via udev?

Reach and flexible build system with UI as comfortable as a brush
and easel for painter? No, i'd better do something else...

ftp://flower.upol.cz/dts/Ash/

i did sorted out (a)sh stuff; kbuild ideas, which are much more
complicated and require at least those improvements to the shell,
i did send some time ago with almost no positive reaction.
Now i pretty much sure, why there was such reaction.

BTW, ash had built-in `test`  `expr`, appeared from nothing
today's odd job, where bash GPL routine is copied instead of Linux's
euidaccess() is a... A little surprise!

http://sourceware.org/ml/libc-alpha/2007-01/msg00099.html
`--http://sourceware.org/ml/libc-alpha/2007-01/msg00105.html

With the flexible build system, which can tune everything easily, such
crap form the software whore, couldn't exist. Does shell know, about new
size of the quanta of the pipe in Linux? One must write m4 autoconf crap?..

200X Monty Python: Crap. Crap, crap crap. Crap? Crap crap!
http://www.youtube.com/watch?v=wZ7YedEopp4
Or...
http://www.adultswim.com/video/?episodeID=8a25c39214b602990114b8a43a37012b

 -
 To unsubscribe from this list: send the line unsubscribe linux-kbuild in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Yes, fsck! I AM SUBSCRIBED! AND I KNOW WHAT TO DO IF I WILL
CHANGE MY MIND!
PLEASE CC ME, I DON'T FOLLOW LKML!!
Oh, crap.
-o--=O`C
 #oo'L O
___=E M
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mkasm-offsets.sh ?

[Oleg Verych]

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 finished? I could sure it (for
> > > pretty much the same reason as lguest).
> >
> > It was, but untested (widely). The (google) search keyword is
> > "asm-values", because there are much more things, than just offsets.
>
> Thanks for the pointer. Could you please provide a Signed-off-by line,
> so that other people can modify and extend your work?

Signed-off-by: Oleg Verych <[EMAIL PROTECTED]>

It was not copyrighted "art" work anyway. Also, i have no access to the original
e-mail service now, sorry.

Hope, this helps.
___
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mkasm-offsets.sh ?

[Oleg Verych]

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 finished? I could sure it (for
   pretty much the same reason as lguest).
 
  It was, but untested (widely). The (google) search keyword is
  asm-values, because there are much more things, than just offsets.

 Thanks for the pointer. Could you please provide a Signed-off-by line,
 so that other people can modify and extend your work?

Signed-off-by: Oleg Verych [EMAIL PROTECTED]

It was not copyrighted art work anyway. Also, i have no access to the original
e-mail service now, sorry.

Hope, this helps.
___
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mkasm-offsets.sh ?

[Oleg Verych]

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 is
"asm-values", because
there are much more things, than just offsets.
__
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mkasm-offsets.sh ?

[Oleg Verych]

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 is
asm-values, because
there are much more things, than just offsets.
__
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

= 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 y/n config option to pull flags from the env?

> > > How about just adding an extra-CFLAGS option to .config and perhaps
> > > a 'make configpickupCFLAGS' pass for anyone who wants to propagate
> > > the environment CFLAGS into the kernel build.
> >
> > I totally disagree.

I do too. Every ordinary (like shell, i.e. which is not setting own env
program) exec*() will copy that mostly useless var for every subshell,
`cat`, `cp`, `mv`...

[]
> > Do you even understand that taking this out of kbuild will just push
> > the problem one level of indirection away?  Say this stupid CFLAGS
> > setting creaps into someone's gcc bootstrap, and that gcc miscompiles
> > the kernel.  You will have fun debugging that too, but I'm sad to say
> > you won't be able to pass the blame to kbuild on that one 8-/
> >
> > It's just more proof that setting CFLAGS globally in your environment
> > is just plain stupid and asking for trouble.
> >
> > Don't do it.
>
> I'm not seeing what's stupid about this.
[]
-- 
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

= 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 y/n config option to pull flags from the env?

   How about just adding an extra-CFLAGS option to .config and perhaps
   a 'make configpickupCFLAGS' pass for anyone who wants to propagate
   the environment CFLAGS into the kernel build.
 
  I totally disagree.

I do too. Every ordinary (like shell, i.e. which is not setting own env
program) exec*() will copy that mostly useless var for every subshell,
`cat`, `cp`, `mv`...

[]
  Do you even understand that taking this out of kbuild will just push
  the problem one level of indirection away?  Say this stupid CFLAGS
  setting creaps into someone's gcc bootstrap, and that gcc miscompiles
  the kernel.  You will have fun debugging that too, but I'm sad to say
  you won't be able to pass the blame to kbuild on that one 8-/
 
  It's just more proof that setting CFLAGS globally in your environment
  is just plain stupid and asking for trouble.
 
  Don't do it.

 I'm not seeing what's stupid about this.
[]
-- 
-o--=O`C
 #oo'L O
___=E M
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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 not entirely sure who to blame on that thing. I'm adding Greg to the 
>> > Cc, on the assumption that blaming him is usually the right thing to do ;)
>> 
>> Hey, it wasn't me this time, I haven't even built my trees for you to
>> pull from and break everything yet :)
>
> No, I meant more in the "who the hell is responsible for designing those 
> *files*" rather than who is responsible for the particular merge mess 
> that happened to involve them this time around.
>
>> But yeah, splitting up the mod_devicetable.h/file2alias.c mess is a very
>> good idea, I'll see what I can come up with tomorrow.
>
> I don't think it's a huge issue, but I wanted to bring it up because these 
> days we're normally so good with these kinds of things that it actually 
> stood out a bit. I used to do these kinds of nasty merges all the time 
> with init/main.c and the configuration files, until we split them up.
>
> So I'm certainly perfectly able and used to doing them, it's just that I 
> also think that we have generally learnt to do so much better.
>
> In other words: no hurry or pressure, I just wanted to bring it up, since 
> during the merge I got flashbacks to various "bad old times" that I had 
> hoped we had mostly left behind.
>
> Those files were originally designed/set up by Rusty. I could have blamed 
> him, or perhaps Sam as a kbuild guy, but the reason I cc'd you is that I 
> think this kind of smells like a "device model"ish thing...

If any amount of work will be done on (re)designing, i'd like to propose
documenting all that mod magic.

OK, it can be figured out from the code, and quick split+script_glue can
be "designed". But if goals and key points would be written in plain text
by person(s) who used to do and maintain it, that will be helpful.

Thanks.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 >4GB physical memory on x86, all fluff?

Are we talking about VGA text mode or VT100 terminals? On what arch
Linux was written to run shell and to build itself?

IBM PC, if you don't know. Thus, your comment isn't funny or serious,
sorry. I also distinguish important, needed, useful, preferable.

> >>(and yes, i have implemented kernel console improvements in the past 
> >>and vga scrollback support was in fact amongst one of my first ever 
> >>Linux kernel hacks so your comment is doubly wrong.)
> >
> >This `scrollback' is usual late boot / console one. If fact useful,
> >until first tty switch or if `screen` cannot be used. But for some
> >reason if scrolling region (DECSTBM) is less than whole screen, nothing
> >works. And if width set to odd number of columns
> >
> >`stty columns $((80-1))`
> >
> >whole output becomes somewhat funny.
> 
> I think by the time you get up enough to be running ill-advised commands 
> from shell, you are past "early boot."

As i did dumb userspace coloring of kernel messages after this post,
where text from bootloader, critical stuff are visible -- i.e. no
truncated scrollback is needed, i can say, that this comment is bogus.

I don't know what `ill-advised' commands are, but knowing how pipefs
wasn't up early in <2.6.2X, i can say: *IT IS EARLY*. By me anything,
that have /dev/console as controlling tty is early.

> Your comments about scrollback not working right if you break it are
> hopefully an attempt at humor.

Cannot comment, because i don't understand this. I want scrollback in a
defined scrolling region; i what line scrolling not be cursed, if columns
number is odd.

Now i have all this in userspace *early*, so i don't care about what
ever implementors of that stuff in kernel thought.

Bye.
--
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 4GB physical memory on x86, all fluff?

Are we talking about VGA text mode or VT100 terminals? On what arch
Linux was written to run shell and to build itself?

IBM PC, if you don't know. Thus, your comment isn't funny or serious,
sorry. I also distinguish important, needed, useful, preferable.

 (and yes, i have implemented kernel console improvements in the past 
 and vga scrollback support was in fact amongst one of my first ever 
 Linux kernel hacks so your comment is doubly wrong.)
 
 This `scrollback' is usual late boot / console one. If fact useful,
 until first tty switch or if `screen` cannot be used. But for some
 reason if scrolling region (DECSTBM) is less than whole screen, nothing
 works. And if width set to odd number of columns
 
 `stty columns $((80-1))`
 
 whole output becomes somewhat funny.
 
 I think by the time you get up enough to be running ill-advised commands 
 from shell, you are past early boot.

As i did dumb userspace coloring of kernel messages after this post,
where text from bootloader, critical stuff are visible -- i.e. no
truncated scrollback is needed, i can say, that this comment is bogus.

I don't know what `ill-advised' commands are, but knowing how pipefs
wasn't up early in 2.6.2X, i can say: *IT IS EARLY*. By me anything,
that have /dev/console as controlling tty is early.

 Your comments about scrollback not working right if you break it are
 hopefully an attempt at humor.

Cannot comment, because i don't understand this. I want scrollback in a
defined scrolling region; i what line scrolling not be cursed, if columns
number is odd.

Now i have all this in userspace *early*, so i don't care about what
ever implementors of that stuff in kernel thought.

Bye.
--
-o--=O`C
 #oo'L O
___=E M
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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 not entirely sure who to blame on that thing. I'm adding Greg to the 
  Cc, on the assumption that blaming him is usually the right thing to do ;)
 
 Hey, it wasn't me this time, I haven't even built my trees for you to
 pull from and break everything yet :)

 No, I meant more in the who the hell is responsible for designing those 
 *files* rather than who is responsible for the particular merge mess 
 that happened to involve them this time around.

 But yeah, splitting up the mod_devicetable.h/file2alias.c mess is a very
 good idea, I'll see what I can come up with tomorrow.

 I don't think it's a huge issue, but I wanted to bring it up because these 
 days we're normally so good with these kinds of things that it actually 
 stood out a bit. I used to do these kinds of nasty merges all the time 
 with init/main.c and the configuration files, until we split them up.

 So I'm certainly perfectly able and used to doing them, it's just that I 
 also think that we have generally learnt to do so much better.

 In other words: no hurry or pressure, I just wanted to bring it up, since 
 during the merge I got flashbacks to various bad old times that I had 
 hoped we had mostly left behind.

 Those files were originally designed/set up by Rusty. I could have blamed 
 him, or perhaps Sam as a kbuild guy, but the reason I cc'd you is that I 
 think this kind of smells like a device modelish thing...

If any amount of work will be done on (re)designing, i'd like to propose
documenting all that mod magic.

OK, it can be figured out from the code, and quick split+script_glue can
be designed. But if goals and key points would be written in plain text
by person(s) who used to do and maintain it, that will be helpful.

Thanks.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 at the if when there's such a long printk() 
> > > in the middle...
> > 
> > printk() problem was discussed with proper banana userspace replacement
> > proposition by me, so i don't care much.
> > 
> > Though, why MCE can't be enabled/disabled by config option? Native
> > engineers from proper company should know what processors have this
> > feature... If kconfig isn't flexible for this, i'm glad to hear
> > opinions. If it's needed anyway, then sorry.
> 
> You should better say sorry for not having checked that it can already 
> be disabled with a kconfig option...

Talk is not about wana-build-MCE-in, given to the user's sake. But about
flexible selection of this code, if it is really supported by CPU, when
user have it enabled (see winchip/preventium sub-thread). More work, it
is not such quick patch, certainly, but this is needed for famous i386.

I wonder, why such patch wasn't introduced long time ago. Modern
(cheap) chips have no MCE?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 replacement
proposition by me, so i don't care much.

Though, why MCE can't be enabled/disabled by config option? Native
engineers from proper company should know what processors have this
feature... If kconfig isn't flexible for this, i'm glad to hear
opinions. If it's needed anyway, then sorry.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 replacement
proposition by me, so i don't care much.

Though, why MCE can't be enabled/disabled by config option? Native
engineers from proper company should know what processors have this
feature... If kconfig isn't flexible for this, i'm glad to hear
opinions. If it's needed anyway, then sorry.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 at the if when there's such a long printk() 
   in the middle...
  
  printk() problem was discussed with proper banana userspace replacement
  proposition by me, so i don't care much.
  
  Though, why MCE can't be enabled/disabled by config option? Native
  engineers from proper company should know what processors have this
  feature... If kconfig isn't flexible for this, i'm glad to hear
  opinions. If it's needed anyway, then sorry.
 
 You should better say sorry for not having checked that it can already 
 be disabled with a kconfig option...

Talk is not about wana-build-MCE-in, given to the user's sake. But about
flexible selection of this code, if it is really supported by CPU, when
user have it enabled (see winchip/preventium sub-thread). More work, it
is not such quick patch, certainly, but this is needed for famous i386.

I wonder, why such patch wasn't introduced long time ago. Modern
(cheap) chips have no MCE?

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 &&
> > > > !(c->x86_capability & (X86_FEATURE_MCA | X86_FEATURE_MCE)) {
> > > > printk(KERN_INFO "CPU%i: No machine check support 
> > > > available\n",
> > > > smp_processor_id());
> > > 
> > > This looks complicated and is harder to read. Its exactly the purpose of 
> > > the
> > > cpu_has() macro to avoid such constructs.
> > 
> > It is done via test_bit(), which is designed for IO access with all that
> > `const volatile' stuff, 2 x unnecessary, can't be optimized here (IMHO).
> 
> If this code is getting called often enough that optimization matters, you
> got *bigger* issues to worry about than optimization.  Looks like it should
> only happen once at boot time.

Text size matters even on static storages. A Linuxbios image not fitting
to the 2M flash, etc.

Thanks.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 || !mce) {
> > > + printk(KERN_INFO "CPU%i: No machine check support available\n",
> > > + smp_processor_id());
> > > + return;
> > > + }
> > > +
> > 
> > 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 available\n",
> > smp_processor_id());
> 
> This looks complicated and is harder to read. Its exactly the purpose of the
> cpu_has() macro to avoid such constructs.
> 
> > return;
> > } else
> > return;
> 
> Return unconditionaly here?

Kind of typo.

Due to arch code, i think, it must be coded in non-gcc optimistic way. As
practice and Linus shows, gcc's optimizations sometimes produce very
unexpected results. People do spaghetti-like coding, without thinking
about text size / run time.

Compile time payment was noted by Andrew many years ago:

"As you know, I'd be more concerned about moves to drop support for the
older and much faster gcc versions.  If you're not using egcs-1.1.2,
you're already a very patient person." 

So, i actually wanted to write this:

if (!mce_disabled) {
if (!(c->x86_capability & (X86_FEATURE_MCA | X86_FEATURE_MCE)) {
printk(KERN_INFO "CPU%i: No machine check support available\n",
smp_processor_id());
return;
}
/* function code */
}

(ugly, because `mce_disabled == 1' check is even in gcc is likely by
default). But changed my mind, due to violation of the coding style.
Of course this my be no appropriate at all, but i'd like to bring
this, if anyone would be like to discuss this.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 available\n",
> > smp_processor_id());
> 
> This looks complicated and is harder to read. Its exactly the purpose of the
> cpu_has() macro to avoid such constructs.

It is done via test_bit(), which is designed for IO access with all that
`const volatile' stuff, 2 x unnecessary, can't be optimized here (IMHO).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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)
>   return;
>  
> + mca = cpu_has(c, X86_FEATURE_MCA);
> + mce = cpu_has(c, X86_FEATURE_MCE);
> +
> + if (!mca || !mce) {
> + printk(KERN_INFO "CPU%i: No machine check support available\n",
> + smp_processor_id());
> + return;
> + }
> +

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 available\n",
smp_processor_id());
return;
} else
return;
?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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
> limitation, a linked list style boot parameter passing mechanism (struct
> setup_data) is proposed by Peter Anvin. The linked list is provided by
> bootloader, so it is possible to be in highmem region.

Can it be explained, why boot protocol and boot line must be expanded?
This amount of code for what?

 arch/i386/Kconfig|3 -
 arch/i386/boot/header.S  |8 +++
 arch/i386/kernel/setup.c |   92 +++
 arch/x86_64/kernel/setup.c   |   37 +
 include/asm-i386/bootparam.h |   15 +++
 include/asm-i386/io.h|7 +++
 include/linux/mm.h   |2
 mm/memory.c  |   24 +++
 

If it is proposed for passing ACPI makeup language bugfixes by boot
line for ACPI parser in the kernel, or "telling to kernel what to do
via EFI" then it's kind of very nasty red flag.

I'd suggest to have initramfs image ready with all possible
data/options/actions based on very small amount of possible boot line
information.

Any _right_ use-cases explained for dummies are appreciated.

Thanks.
--
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 to make fast and easy (text/tty)
user interface, based solely on TERM=linux capability. It is such, but
deep in ncurses/lxdialog wrappers. Having more flexible TUI without
all past stereotypes is the major point in making any progress for
flexible configuration interface. Remember, how blind `select` hurts.
It does due to UI limitations in first place, IMHO.

> 2) We need to share much more Kconfig* between the individual architectures
>First step is to let all arch's use drivers/Kconfig

All syntax wars are over, now order is the second thing to achieve. Like
in x86 merge case, this is purely technical thing with a bit of manual
work after that. sed magic for (nearly any kind :) of textual processing
i can guarantee without (yet another) C (like fixdep.c, parts of
sumversion.c, etc.)

> Let's get the two items above solved then we can revisit adding arch selection
> to kconfig (where it belongs in the end).
> And neither require a rewrite of kconfig...

Since i try to do test driven development, it's more easy for me to
understand/fix/test today's things via making bits from scratch. Fresh
view can do more on debugging of the logic level also.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 to make fast and easy (text/tty)
user interface, based solely on TERM=linux capability. It is such, but
deep in ncurses/lxdialog wrappers. Having more flexible TUI without
all past stereotypes is the major point in making any progress for
flexible configuration interface. Remember, how blind `select` hurts.
It does due to UI limitations in first place, IMHO.

 2) We need to share much more Kconfig* between the individual architectures
First step is to let all arch's use drivers/Kconfig

All syntax wars are over, now order is the second thing to achieve. Like
in x86 merge case, this is purely technical thing with a bit of manual
work after that. sed magic for (nearly any kind :) of textual processing
i can guarantee without (yet another) C (like fixdep.c, parts of
sumversion.c, etc.)

 Let's get the two items above solved then we can revisit adding arch selection
 to kconfig (where it belongs in the end).
 And neither require a rewrite of kconfig...

Since i try to do test driven development, it's more easy for me to
understand/fix/test today's things via making bits from scratch. Fresh
view can do more on debugging of the logic level also.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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
 limitation, a linked list style boot parameter passing mechanism (struct
 setup_data) is proposed by Peter Anvin. The linked list is provided by
 bootloader, so it is possible to be in highmem region.

Can it be explained, why boot protocol and boot line must be expanded?
This amount of code for what?

 arch/i386/Kconfig|3 -
 arch/i386/boot/header.S  |8 +++
 arch/i386/kernel/setup.c |   92 +++
 arch/x86_64/kernel/setup.c   |   37 +
 include/asm-i386/bootparam.h |   15 +++
 include/asm-i386/io.h|7 +++
 include/linux/mm.h   |2
 mm/memory.c  |   24 +++
 

If it is proposed for passing ACPI makeup language bugfixes by boot
line for ACPI parser in the kernel, or telling to kernel what to do
via EFI then it's kind of very nasty red flag.

I'd suggest to have initramfs image ready with all possible
data/options/actions based on very small amount of possible boot line
information.

Any _right_ use-cases explained for dummies are appreciated.

Thanks.
--
-o--=O`C
 #oo'L O
___=E M
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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)
   return;
  
 + mca = cpu_has(c, X86_FEATURE_MCA);
 + mce = cpu_has(c, X86_FEATURE_MCE);
 +
 + if (!mca || !mce) {
 + printk(KERN_INFO CPU%i: No machine check support available\n,
 + smp_processor_id());
 + return;
 + }
 +

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 available\n,
smp_processor_id());
return;
} else
return;
?

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 available\n,
  smp_processor_id());
 
 This looks complicated and is harder to read. Its exactly the purpose of the
 cpu_has() macro to avoid such constructs.

It is done via test_bit(), which is designed for IO access with all that
`const volatile' stuff, 2 x unnecessary, can't be optimized here (IMHO).

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 || !mce) {
   + printk(KERN_INFO CPU%i: No machine check support available\n,
   + smp_processor_id());
   + return;
   + }
   +
  
  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 available\n,
  smp_processor_id());
 
 This looks complicated and is harder to read. Its exactly the purpose of the
 cpu_has() macro to avoid such constructs.
 
  return;
  } else
  return;
 
 Return unconditionaly here?

Kind of typo.

Due to arch code, i think, it must be coded in non-gcc optimistic way. As
practice and Linus shows, gcc's optimizations sometimes produce very
unexpected results. People do spaghetti-like coding, without thinking
about text size / run time.

Compile time payment was noted by Andrew many years ago:

As you know, I'd be more concerned about moves to drop support for the
older and much faster gcc versions.  If you're not using egcs-1.1.2,
you're already a very patient person. http://lkml.org/lkml/2001/12/29/163

So, i actually wanted to write this:

if (!mce_disabled) {
if (!(c-x86_capability  (X86_FEATURE_MCA | X86_FEATURE_MCE)) {
printk(KERN_INFO CPU%i: No machine check support available\n,
smp_processor_id());
return;
}
/* function code */
}

(ugly, because `mce_disabled == 1' check is even in gcc is likely by
default). But changed my mind, due to violation of the coding style.
Of course this my be no appropriate at all, but i'd like to bring
this, if anyone would be like to discuss this.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 
!(c-x86_capability  (X86_FEATURE_MCA | X86_FEATURE_MCE)) {
printk(KERN_INFO CPU%i: No machine check support 
available\n,
smp_processor_id());
   
   This looks complicated and is harder to read. Its exactly the purpose of 
   the
   cpu_has() macro to avoid such constructs.
  
  It is done via test_bit(), which is designed for IO access with all that
  `const volatile' stuff, 2 x unnecessary, can't be optimized here (IMHO).
 
 If this code is getting called often enough that optimization matters, you
 got *bigger* issues to worry about than optimization.  Looks like it should
 only happen once at boot time.

Text size matters even on static storages. A Linuxbios image not fitting
to the 2M flash, etc.

Thanks.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: reviewer's statement of oversight

[Oleg Verych]

* 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 authority of the person acking, 
>> reviewing, testing, or nacking.  That's only as good as the trust in the 
>> person signing.
>
> I would tend to agree.  Right now I think the problem is that we are
> getting too little reviews, not enough.  And someone who reviews
> patches, even if unknown, could be building up expertise that
> eventually would make them a valued developer, even while they are
> doing us a service.   

Experience of convincing experienced patch author, that some things in
the patch are wrong :)

[]
> We could ask reviewers to include a URL to an LKML archive of their
> review, to make it easier to find a review of a patch so later on
> people can judge how effective they their review was.

I vote for more little summaries in the `Subject'(again). Long, boring
threads with whole threading part of screen being empty due to same
subjects isn't fun, when some of thousands of messages can have
interesting stuff inside.

And it's easy not only for mailing list readers now, and for archive
readers also; readers of the www search results (who ever that may be):

google.com/search?q=reviewed+crashkernel

First hit on the review of the patch, i happened to make. And i just
thought "hell, just string parsing, what can be more simply?", yet there
was productive discussion and bug fixing. After i saw convincing
statements about testing, i've placed review mark. Though i'm really
"unimportant" random hacker.
--
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 scratch.
> 
> But it's your decision and not mine.

In case anybody is interested:

Newsgroups: gmane.linux.kbuild.devel,gmane.linux.kernel
Subject: Re: [RFC/RFT] kbuild: save ARCH & CROSS_COMPILE
Date: Mon, 8 Oct 2007 22:50:48 +0200
Message-ID: <[EMAIL PROTECTED]>
Archived-At: 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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
written to the .config?

The zeroth one is an config entry of kernel version(s), .config can
configure and thus build successfully.


This are among other ideas about kconfig/kbuild, you know nothing
about yet.

So, what do you think?

Also, i'd like to propose sequencing of config-enable-build-this-unit
in config file(s), thus Makefile(s) (sometimes very small and stupid)
will be not necessary. Additional link ordering can be supplied as
meta-config information there. Shell scripting, very ugly in the view
of make syntax, will be natural in config files. Extending build
process to get hidden dependencies or right linking/other magic is
part of particular configuration. Hm?

And i want to repeat this to the wall:

make is stupid `test -nt` (non POSIX, but accepted my shells and GNU test
feature). Making any kind of hashing to make dream of kbuild-2.5
developers/fans -- more complete `up-to-date' heuristic possible, is just
like `md5sum > $OBJDIR/heuristic.com`, which is config selectable (for
those, who don't like a bit of slowdown).
--
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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. Here, having the ability to see that no IRQ was
> > > assigned or something like this could help.
> > 
> > As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after
> > some time i will propose something klibc/tty based. Mainly a bit of user
> > interface: split scrolling regions for errors and notifications; flexible
> > color schemas (keyword highlighting); keyboard events. Of course it will
> > work in such IDE cases, only if driver is a module.
> 
> But what I cannot understand is how you expect userspace to work while
> the lines are being displayed.

With `quiet' boot option no message bloat is flowing. I have on debian's
2.6.18 only two error message about PCI remaing error and if by buggy
grub didn't read initrd image correctly, so ungziping fails.

> If this is just to repaint the screen once everything is up, it is 100%
> useless. I'm interested in seeing errors _while_ they are happening.
> Basically, I need no color if the machine boots correctly.

OK. I don't know what somebody think it is like, let me show,
especially for our famous kernel developer.

In flower ftp upload adopted "init" script for initramfs can be found.
I took standard debian's and added  my stuff on head.

With quiet option kernel (should) very quickly reach initramfs/init.
Even 4M gzipped image (14M unpacked) on my laptop loads pretty quickly.

All is nice looking and scrollable (a bit). I didn't tried to do
separate scrolling regions for info and errors, because back scrolling
would be dead. But if somebody will fix this kernel feature, things
can be done easily then. Or file backup can used instead, early dmesg
available as a side effect.

So, i let see colored messages even for very old kernels, if this head
is added to initramfs/init. If it doesn't work for you, let's make it
work!

(sh: `sleep` must not be from busybox, because it has no seconds
fractions, which is kind of stupid, but POSIX compatible. My proposition
about select() like tool for shell can be found in google:
'olecom select sh')

== Script makes basic fs setup: ==

#!/bin/sh
# NOTE: pipefs (in <2.6.2?) isn't up yet
set +e

test  -e null || mknod null c 1 3
{
mkdir -m 0755 /dev
mkdir -m 1777 /tmp
mkdir -m 0555 /proc
cd /dev
mknod null c 1 3
mknod kmsg c 1 11
mknod tty  c 5 0
mknod console c 5 1
} 2>null

umask 077
mount -t proc proc /proc


== then TERM=linux tty loglevel attributes setup: 

DEF='\033[0m'
EMERG='\033[1;5;37;41m' # bold blink white fore- on red background
ALERT='\033[1;37;41m'
CRIT='\033[1;5;31;40m'  # bold blink red on black
ERR='\033[1;31;40m'
WARN='\033[1;33;40m'# bold yellow,
NOTICE='\033[1;36;40m'  # cyan
INFO='\033[1;32;40m'# green
DBG='\033[1;34;40m' # blue
q='\033[1;35m`'
b="\033[1;35m'"


== polling/printing daemon setup 

kttylog() {
# in case of rootfs change die
# (rerun manually in the end of the init script with new rootfs)
set -e
trap '
echo "reloading kttylogd, new pid=$!" >/dev/kmsg
exit
' EXIT HUP

while read -r LINE
   do case  "$LINE" in
'<0'*) COLOR=EMERG;;
'<1'*) COLOR=ALERT;;
'<2'*) COLOR=CRIT;;
'<3'*) COLOR=ERR;;
'<4'*) COLOR=WARN;;
'<5'*) COLOR=NOTICE;;
'<7'*) COLOR=DBG;;
esac
# turn name to value
eval 'printf "$'"${COLOR=INFO}"'"'
# print raw content
printf %s "${LINE#???}"
# finish line output
printf "$DEF\n\r"
done
}

== wait to see all "quiet" messages ==

printf "
After you've seen errors, even with $q\033[33mquiet$b$DEF option,
to see other (usual) printk() stuff and continue to boot,
please, hurry to press $q\033[0;1mEnter$b$DEF
"
fancy_read() {
TIMEOUT=7  # bash has seconds-only there, but we can have all,
   # that (klibc's) `sleep' can (it has useful fractions, POSIX hasn't)
   # Peter (hpa) did bash-incomatible change in klibc's `read`,
   # added `-t', added with second fractions :(
   # this functions is an example to show, that by means of `sh`
   # it's possible to have *fancy* read (i.e. nice and flexible

POLLTIME=5 # tenths of seconds
TIMEOUT=${TIMEOUT}0
PROMPT="("
G=$((${#PROMPT} + 1))
PROMPT="$PROMPT$TIMEOUT): "

echo -n "$PROMPT"
exec 4<&0 # /dev/tty isn't working early, thus do dup of stdin for `read' job
( read LAMER_LEVEL || echo "Read Error" ) <&4 &
exec 4<&-

INPUT_PID=$!

while /bin/sleep 

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

[Oleg Verych]

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. Here, having the ability to see that no IRQ was
   assigned or something like this could help.
  
  As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after
  some time i will propose something klibc/tty based. Mainly a bit of user
  interface: split scrolling regions for errors and notifications; flexible
  color schemas (keyword highlighting); keyboard events. Of course it will
  work in such IDE cases, only if driver is a module.
 
 But what I cannot understand is how you expect userspace to work while
 the lines are being displayed.

With `quiet' boot option no message bloat is flowing. I have on debian's
2.6.18 only two error message about PCI remaing error and if by buggy
grub didn't read initrd image correctly, so ungziping fails.

 If this is just to repaint the screen once everything is up, it is 100%
 useless. I'm interested in seeing errors _while_ they are happening.
 Basically, I need no color if the machine boots correctly.

OK. I don't know what somebody think it is like, let me show,
especially for our famous kernel developer.

In flower ftp upload adopted init script for initramfs can be found.
I took standard debian's and added  my stuff on head.

With quiet option kernel (should) very quickly reach initramfs/init.
Even 4M gzipped image (14M unpacked) on my laptop loads pretty quickly.

All is nice looking and scrollable (a bit). I didn't tried to do
separate scrolling regions for info and errors, because back scrolling
would be dead. But if somebody will fix this kernel feature, things
can be done easily then. Or file backup can used instead, early dmesg
available as a side effect.

So, i let see colored messages even for very old kernels, if this head
is added to initramfs/init. If it doesn't work for you, let's make it
work!

(sh: `sleep` must not be from busybox, because it has no seconds
fractions, which is kind of stupid, but POSIX compatible. My proposition
about select() like tool for shell can be found in google:
'olecom select sh')

== Script makes basic fs setup: ==

#!/bin/sh
# NOTE: pipefs (in 2.6.2?) isn't up yet
set +e

test  -e null || mknod null c 1 3
{
mkdir -m 0755 /dev
mkdir -m 1777 /tmp
mkdir -m 0555 /proc
cd /dev
mknod null c 1 3
mknod kmsg c 1 11
mknod tty  c 5 0
mknod console c 5 1
} 2null

umask 077
mount -t proc proc /proc


== then TERM=linux tty loglevel attributes setup: 

DEF='\033[0m'
EMERG='\033[1;5;37;41m' # bold blink white fore- on red background
ALERT='\033[1;37;41m'
CRIT='\033[1;5;31;40m'  # bold blink red on black
ERR='\033[1;31;40m'
WARN='\033[1;33;40m'# bold yellow,
NOTICE='\033[1;36;40m'  # cyan
INFO='\033[1;32;40m'# green
DBG='\033[1;34;40m' # blue
q='\033[1;35m`'
b=\033[1;35m'


== polling/printing daemon setup 

kttylog() {
# in case of rootfs change die
# (rerun manually in the end of the init script with new rootfs)
set -e
trap '
echo reloading kttylogd, new pid=$! /dev/kmsg
exit
' EXIT HUP

while read -r LINE
   do case  $LINE in
'0'*) COLOR=EMERG;;
'1'*) COLOR=ALERT;;
'2'*) COLOR=CRIT;;
'3'*) COLOR=ERR;;
'4'*) COLOR=WARN;;
'5'*) COLOR=NOTICE;;
'7'*) COLOR=DBG;;
esac
# turn name to value
eval 'printf $'${COLOR=INFO}''
# print raw content
printf %s ${LINE#???}
# finish line output
printf $DEF\n\r
done
}

== wait to see all quiet messages ==

printf 
After you've seen errors, even with $q\033[33mquiet$b$DEF option,
to see other (usual) printk() stuff and continue to boot,
please, hurry to press $q\033[0;1mEnter$b$DEF

fancy_read() {
TIMEOUT=7  # bash has seconds-only there, but we can have all,
   # that (klibc's) `sleep' can (it has useful fractions, POSIX hasn't)
   # Peter (hpa) did bash-incomatible change in klibc's `read`,
   # added `-t', added with second fractions :(
   # this functions is an example to show, that by means of `sh`
   # it's possible to have *fancy* read (i.e. nice and flexible

POLLTIME=5 # tenths of seconds
TIMEOUT=${TIMEOUT}0
PROMPT=(
G=$((${#PROMPT} + 1))
PROMPT=$PROMPT$TIMEOUT): 

echo -n $PROMPT
exec 40 # /dev/tty isn't working early, thus do dup of stdin for `read' job
( read LAMER_LEVEL || echo Read Error ) 4 
exec 4-

INPUT_PID=$!

while /bin/sleep 0.$POLLTIME  test -e /proc/$INPUT_PID/exe
do
   TIMEOUT=$((${TIMEOUT} - $POLLTIME))

   if test $TIMEOUT -gt 0
   then printf \0337\033[${G}G$TIMEOUT): \0338
   else printf \033[${G}Gtime is out)
test -e /proc/$INPUT_PID/exe  kill $INPUT_PID
break
   fi
done
}

fancy_read
unset fancy_read


== run printing daemon

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

[Oleg Verych]

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
written to the .config?

The zeroth one is an config entry of kernel version(s), .config can
configure and thus build successfully.


This are among other ideas about kconfig/kbuild, you know nothing
about yet.

So, what do you think?

Also, i'd like to propose sequencing of config-enable-build-this-unit
in config file(s), thus Makefile(s) (sometimes very small and stupid)
will be not necessary. Additional link ordering can be supplied as
meta-config information there. Shell scripting, very ugly in the view
of make syntax, will be natural in config files. Extending build
process to get hidden dependencies or right linking/other magic is
part of particular configuration. Hm?

And i want to repeat this to the wall:

make is stupid `test -nt` (non POSIX, but accepted my shells and GNU test
feature). Making any kind of hashing to make dream of kbuild-2.5
developers/fans -- more complete `up-to-date' heuristic possible, is just
like `md5sum  $OBJDIR/heuristic.com`, which is config selectable (for
those, who don't like a bit of slowdown).
--
-o--=O`C
 #oo'L O
___=E M
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 scratch.
 
 But it's your decision and not mine.

In case anybody is interested:

Newsgroups: gmane.linux.kbuild.devel,gmane.linux.kernel
Subject: Re: [RFC/RFT] kbuild: save ARCH  CROSS_COMPILE
Date: Mon, 8 Oct 2007 22:50:48 +0200
Message-ID: [EMAIL PROTECTED]
Archived-At: http://permalink.gmane.org/gmane.linux.kbuild.devel/1562

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: reviewer's statement of oversight

[Oleg Verych]

* 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 authority of the person acking, 
 reviewing, testing, or nacking.  That's only as good as the trust in the 
 person signing.

 I would tend to agree.  Right now I think the problem is that we are
 getting too little reviews, not enough.  And someone who reviews
 patches, even if unknown, could be building up expertise that
 eventually would make them a valued developer, even while they are
 doing us a service.   

Experience of convincing experienced patch author, that some things in
the patch are wrong :)

[]
 We could ask reviewers to include a URL to an LKML archive of their
 review, to make it easier to find a review of a patch so later on
 people can judge how effective they their review was.

I vote for more little summaries in the `Subject'(again). Long, boring
threads with whole threading part of screen being empty due to same
subjects isn't fun, when some of thousands of messages can have
interesting stuff inside.

And it's easy not only for mailing list readers now, and for archive
readers also; readers of the www search results (who ever that may be):

google.com/search?q=reviewed+crashkernel

First hit on the review of the patch, i happened to make. And i just
thought hell, just string parsing, what can be more simply?, yet there
was productive discussion and bug fixing. After i saw convincing
statements about testing, i've placed review mark. Though i'm really
unimportant random hacker.
--
-o--=O`C
 #oo'L O
___=E M
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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_^_'$COLOR1'_
> >/^<2/s_^_'$COLOR2'_
> >/^<3/s_^_'$COLOR3'_
> >/^<4/s_^_'$COLOR4'_
> >/^<5/s_^_'$COLOR5'_
> >/^<6/s_^_'$COLOR6'_
> >/^<7/s_^_'$COLOR7'_
> >' < /proc/kmsg >/dev/tty
> >
> >place whole that perl shit on initrams of your kernel, run it in
> >background as early as possible with switched off default console output
> >(i.e. quiet boot).
> >
> >OVER.
> 
> Speaking of over, this does not fly at all. If you call panic(),
> for whatever reason you want, then the printk() is the last thing
> that happens after that, you can declare userspace dead.
> On oopses, it depends on their severity. Eventually procfs goes
> whoops and the kmsg transmission mechanism does not work, and oh,
> userspace can't help it.

I can rephrase/repeat: Here's discussion about general usage and feature
set.

The Development/debugging of the kernel, especially early boot or hard
core OOPs isn't covered. If a kernel developer wants to have nice looking
OOPes, i bet, this has nothing to do with general purpose printk() and
loglevels and the kernel, that usually must boot once, until next
security update.

This is just another debugging tool, that could be written faster than
any of the fancy rewrites of the kernel's core. Written many many
years ago with much reacher coloring features.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 good thing. RAID 
> > errors, devices disabled due to command-line parameters, and general 
> > anomalies which can cause a hang or panic a few line laters are worth 
> > coloring. And I don't believe in userland's help here, because for 
> > that type of messages, the indication should be returned immediately. 
> > 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. Here, having the ability to see that no IRQ was 
> > assigned or something like this could help.
> 
> Exactly. I'm also testing older distros quite regularly with new kernels 
> and there's it's useful to have an impression of a kernel's output at a 
> glance.

> Adding _any_ userspace change (even if i wanted to do it, which i dont)
> is out of question.

TERM=linux attribute escape codes did not change for a decade (or so).

Making greping and coloring in userspace by means of klibc (+ GNU sed)
and initramfs will solve this easily, provided there's useful
kernel->console[userspace] interface. Ugly hacks, like those patches,
aren't for my view of an useful feature.

> So these are distinct, well-defined usecases that nobody has brought
> any coherent argument against yet. VGA isnt going away anytime soon,
> certainly not on my testboxes.

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_^_'$COLOR1'_
/^<2/s_^_'$COLOR2'_
/^<3/s_^_'$COLOR3'_
/^<4/s_^_'$COLOR4'_
/^<5/s_^_'$COLOR5'_
/^<6/s_^_'$COLOR6'_
/^<7/s_^_'$COLOR7'_
' < /proc/kmsg >/dev/tty

place whole that perl shit on initrams of your kernel, run it in
background as early as possible with switched off default console output
(i.e. quiet boot).

OVER.

For really good output it would be better to have escape code to
serialize printing, thus no coloring brain damage will appear in
concurrent writes on the tty (multiple areas, cursor movements). And this
is only start of what can be done here.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 with it. One for shell in `mcedit` is much nicer, but
`emacs` is more powerful as editor(R). But both have highlighting
problems with non trivial scripts (quoiting, data here, etc). I don't
know if it will ever be fixed :).

Comprehensive highlighting of contents of diffs (or even _patched_
sources) is XXII century feature.

Anyway if anybody have anything to look onto, like more Linux C types,
bogus coding style highlighting, i'll be glad to test. And any
emacs hacks, that gurus are using will be very appreciated.

[0] emacs setup and fontlocking <ftp://flower.upol.cz/emacs/>

> >I use default blue (which is very annoying)
> 
> If blue were annoying, it would not be the default Windows background
> (since Windows 2000). Then again, it's personal preference,

Emacs have black background by default. I changed foreground to green,
and it is much nicer for long runs. Blue (or any bright) background
isn't comfortable, i think.

> so I suppose you have a red/green desktop wallpaper for X11?

Black background mostly. If you know classic blackbox wm (version <=
0.62), then Rancor(80%) and Artwiz(20%) my all time styles. But i use
no X for quite some time now.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 vt.printk_color=9,9,9,9,11,10,12, 
> >> this
> >> is not what serious people would do.
> >> 
> >> [1] http://tinyurl.com/yr9zgq
> >> [2] http://tinyurl.com/234ba3
> >
> > Given this discussion, I find it really appropriate that you are posting
> > _graphics_ of your text screens :-)
> 
> I can give you a VCSA file (as produced by /dev/vcsa1) if you like,
> complete with VCSA reader.

In fact mc config (ini) section is a better way.

I use default blue (which is very annoying) for root user, to be aware of
possible results. Otherwise i use black background:

[Colors]
color_terminals=linux,xterm
base_color=normal=lightgray,black:marked=magenta,black:executable=green,black:directory=lightgray,black:editnormal=green,black:editbold=red,black

The most exiting event recently was, that `lynx` in debian got updated, so
it displays much more colors for HTML formatting now. I'm happy.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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.
> > >
> > >Congratulations, this is the most stupid argument i've ever read on 
> > >lkml.
[]
> 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 good thing. RAID errors,
> devices disabled due to command-line parameters, and general anomalies
> which can cause a hang or panic a few line laters are worth coloring.

That *is* the coloring, i'm talking about.

> And I don't believe in userland's help here, because for that type of
> messages, the indication should be returned immediately.

In the very buggy cases, i think, everything just hang. Otherwise
initramfs stuff can deal with it.

> 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. Here, having the ability to see that no IRQ was
> assigned or something like this could help.

As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after
some time i will propose something klibc/tty based. Mainly a bit of user
interface: split scrolling regions for errors and notifications; flexible
color schemas (keyword highlighting); keyboard events. Of course it will
work in such IDE cases, only if driver is a module.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 
> > > want a color code at glance if something hangs in early bootup) 
> > > Nothing will color-code crashes, etc., etc. Control of the _kernel_ 
> > > console by user-space is complete nonsense.
> > 
> > If it is so important for major kernel developer like you, Ingo, then 
> > why there's no scrollback at first place? Why nothing like that was 
> > not implemented up until now?

To clarify. `Scrollback' here is *useful* scrollback during early boot
and OOPs (which is absent, AFAIK), "nothing like that" is coloring of the
messages by loglevel.

> even if it were true (which it isnt), that is not an argument against 
> including a useful change that exists now and that people are interested 
> in.

Coloring isn't useful. If it was, it would be implemented ~16 years ago.

> (and yes, i have implemented kernel console improvements in the past 
> and vga scrollback support was in fact amongst one of my first ever 
> Linux kernel hacks so your comment is doubly wrong.)

This `scrollback' is usual late boot / console one. If fact useful,
until first tty switch or if `screen` cannot be used. But for some
reason if scrolling region (DECSTBM) is less than whole screen, nothing
works. And if width set to odd number of columns

`stty columns $((80-1))`

whole output becomes somewhat funny.

> > My first ever Linux hack was changing default console output color. I 
> > think it was seven years ago. I though, it was not serious, if nobody 
> > did that already (in the 2.2.14).
> > 
> > Please, don't mix important stuff here. I know, what kernel console 
> > is.
> 
> your arguments are not an answer to my technical points, which i'll 
> repeat here:
> 
> | | [...] No user-space runs during early bootup. (and yes i want a 
> | | color code at glance if something hangs in early bootup)

The kernel developer talks about what is important to him. This is not
technical point.

> | | Nothing will color-code crashes, etc., etc.

Because without userspace kernel panics. And if something is broken very
early, then time to do kernel development better (not to break working
early booting stuff for everybody), rather than to talk about importance
of the color. I think, same applies to kernel debugger, that still
is not in mainline (AFAIK).

> | | Control of the _kernel_ console by user-space is complete nonsense.

Not control, but flexible coloring (any kind of highlighting), selecting
of useful information, i.e. making output more user friendly. This are
things, which all *users* (not developers) expect in boot process of the
one's _machine_, as opposed to debugging (early boot) kernel bugs.

> today's console code development goes in exactly the opposite direction: 
> we are including (formerly-) user-space console functionality in the 
> kernel so that we can for example print oopses even if we are in X mode.

I'm not sure what kind of printing it is. I do not use X much, but when i
did, i recall MCE messages in xterm, when over-clocked CPU was going
crazy, though.

> > > this is nice and 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 are "Oleg Verych && NAK". In case if `NAK' have a magic 
> > meaning in the LKML, like control characters in the tty, i'm sorry.
> 
> yes, a 'NAK' has a particular meaning on lkml.

But what about (NAK && ! any_important_kernel_developer_name)?

> > But how to express opinion quickly and easily?
> 
> by writing a quick email expressing your opinion and waiting to see the 
> discussion play out itself ...

Quick is not for me (i did accepted "config NO" size reduction review,
btw), but for those, who reads LKML or looks on archive search results.

I just am amazed how `Subject' is miss-used. I personally like to have
most of the interesting information gathered from all that thousands of
(not only LKML) messages. But a thread with all-like-one subjects,
subjects that for some reason are taking place on the screen of
MUAs (empty space if they are the same). Thus, short (easy to get right)
summary in subject is more that welcome by me.

> but it is very rude to 'NAK' a patch and it should only be 

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

[Oleg Verych]

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 
   want a color code at glance if something hangs in early bootup) 
   Nothing will color-code crashes, etc., etc. Control of the _kernel_ 
   console by user-space is complete nonsense.
  
  If it is so important for major kernel developer like you, Ingo, then 
  why there's no scrollback at first place? Why nothing like that was 
  not implemented up until now?

To clarify. `Scrollback' here is *useful* scrollback during early boot
and OOPs (which is absent, AFAIK), nothing like that is coloring of the
messages by loglevel.

 even if it were true (which it isnt), that is not an argument against 
 including a useful change that exists now and that people are interested 
 in.

Coloring isn't useful. If it was, it would be implemented ~16 years ago.

 (and yes, i have implemented kernel console improvements in the past 
 and vga scrollback support was in fact amongst one of my first ever 
 Linux kernel hacks so your comment is doubly wrong.)

This `scrollback' is usual late boot / console one. If fact useful,
until first tty switch or if `screen` cannot be used. But for some
reason if scrolling region (DECSTBM) is less than whole screen, nothing
works. And if width set to odd number of columns

`stty columns $((80-1))`

whole output becomes somewhat funny.

  My first ever Linux hack was changing default console output color. I 
  think it was seven years ago. I though, it was not serious, if nobody 
  did that already (in the 2.2.14).
  
  Please, don't mix important stuff here. I know, what kernel console 
  is.
 
 your arguments are not an answer to my technical points, which i'll 
 repeat here:
 
 | | [...] No user-space runs during early bootup. (and yes i want a 
 | | color code at glance if something hangs in early bootup)

The kernel developer talks about what is important to him. This is not
technical point.

 | | Nothing will color-code crashes, etc., etc.

Because without userspace kernel panics. And if something is broken very
early, then time to do kernel development better (not to break working
early booting stuff for everybody), rather than to talk about importance
of the color. I think, same applies to kernel debugger, that still
is not in mainline (AFAIK).

 | | Control of the _kernel_ console by user-space is complete nonsense.

Not control, but flexible coloring (any kind of highlighting), selecting
of useful information, i.e. making output more user friendly. This are
things, which all *users* (not developers) expect in boot process of the
one's _machine_, as opposed to debugging (early boot) kernel bugs.

 today's console code development goes in exactly the opposite direction: 
 we are including (formerly-) user-space console functionality in the 
 kernel so that we can for example print oopses even if we are in X mode.

I'm not sure what kind of printing it is. I do not use X much, but when i
did, i recall MCE messages in xterm, when over-clocked CPU was going
crazy, though.

   this is nice and 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 are Oleg Verych  NAK. In case if `NAK' have a magic 
  meaning in the LKML, like control characters in the tty, i'm sorry.
 
 yes, a 'NAK' has a particular meaning on lkml.

But what about (NAK  ! any_important_kernel_developer_name)?

  But how to express opinion quickly and easily?
 
 by writing a quick email expressing your opinion and waiting to see the 
 discussion play out itself ...

Quick is not for me (i did accepted config NO size reduction review,
btw), but for those, who reads LKML or looks on archive search results.

I just am amazed how `Subject' is miss-used. I personally like to have
most of the interesting information gathered from all that thousands of
(not only LKML) messages. But a thread with all-like-one subjects,
subjects that for some reason are taking place on the screen of
MUAs (empty space if they are the same). Thus, short (easy to get right)
summary in subject is more that welcome by me.

 but it is very rude to 'NAK' a patch and it should only be done 
 carefully.

That was a review of the implementation, an opinion on whole idea. Idea
of yet another ugly kernel functionality, just because *BSD kernels have
one.

I like highlighting, i like to make it very flexible, nice and
interesting[0]. This is possible only in the userspace, right after first
process ran from initramfs. This happens very quickly usually. And yes,
this is not acceptable/available for kernel developers

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

[Oleg Verych]

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.
  
  Congratulations, this is the most stupid argument i've ever read on 
  lkml.
[]
 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 good thing. RAID errors,
 devices disabled due to command-line parameters, and general anomalies
 which can cause a hang or panic a few line laters are worth coloring.

That *is* the coloring, i'm talking about.

 And I don't believe in userland's help here, because for that type of
 messages, the indication should be returned immediately.

In the very buggy cases, i think, everything just hang. Otherwise
initramfs stuff can deal with it.

 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. Here, having the ability to see that no IRQ was
 assigned or something like this could help.

As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after
some time i will propose something klibc/tty based. Mainly a bit of user
interface: split scrolling regions for errors and notifications; flexible
color schemas (keyword highlighting); keyboard events. Of course it will
work in such IDE cases, only if driver is a module.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 vt.printk_color=9,9,9,9,11,10,12, 
  this
  is not what serious people would do.
  
  [1] http://tinyurl.com/yr9zgq
  [2] http://tinyurl.com/234ba3
 
  Given this discussion, I find it really appropriate that you are posting
  _graphics_ of your text screens :-)
 
 I can give you a VCSA file (as produced by /dev/vcsa1) if you like,
 complete with VCSA reader.

In fact mc config (ini) section is a better way.

I use default blue (which is very annoying) for root user, to be aware of
possible results. Otherwise i use black background:

[Colors]
color_terminals=linux,xterm
base_color=normal=lightgray,black:marked=magenta,black:executable=green,black:directory=lightgray,black:editnormal=green,black:editbold=red,black

The most exiting event recently was, that `lynx` in debian got updated, so
it displays much more colors for HTML formatting now. I'm happy.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 with it. One for shell in `mcedit` is much nicer, but
`emacs` is more powerful as editor(R). But both have highlighting
problems with non trivial scripts (quoiting, data here, etc). I don't
know if it will ever be fixed :).

Comprehensive highlighting of contents of diffs (or even _patched_
sources) is XXII century feature.

Anyway if anybody have anything to look onto, like more Linux C types,
bogus coding style highlighting, i'll be glad to test. And any
emacs hacks, that gurus are using will be very appreciated.

[0] emacs setup and fontlocking ftp://flower.upol.cz/emacs/

 I use default blue (which is very annoying)
 
 If blue were annoying, it would not be the default Windows background
 (since Windows 2000). Then again, it's personal preference,

Emacs have black background by default. I changed foreground to green,
and it is much nicer for long runs. Blue (or any bright) background
isn't comfortable, i think.

 so I suppose you have a red/green desktop wallpaper for X11?

Black background mostly. If you know classic blackbox wm (version =
0.62), then Rancor(80%) and Artwiz(20%) my all time styles. But i use
no X for quite some time now.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 good thing. RAID 
  errors, devices disabled due to command-line parameters, and general 
  anomalies which can cause a hang or panic a few line laters are worth 
  coloring. And I don't believe in userland's help here, because for 
  that type of messages, the indication should be returned immediately. 
  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. Here, having the ability to see that no IRQ was 
  assigned or something like this could help.
 
 Exactly. I'm also testing older distros quite regularly with new kernels 
 and there's it's useful to have an impression of a kernel's output at a 
 glance.

 Adding _any_ userspace change (even if i wanted to do it, which i dont)
 is out of question.

TERM=linux attribute escape codes did not change for a decade (or so).

Making greping and coloring in userspace by means of klibc (+ GNU sed)
and initramfs will solve this easily, provided there's useful
kernel-console[userspace] interface. Ugly hacks, like those patches,
aren't for my view of an useful feature.

 So these are distinct, well-defined usecases that nobody has brought
 any coherent argument against yet. VGA isnt going away anytime soon,
 certainly not on my testboxes.

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_^_'$COLOR1'_
/^2/s_^_'$COLOR2'_
/^3/s_^_'$COLOR3'_
/^4/s_^_'$COLOR4'_
/^5/s_^_'$COLOR5'_
/^6/s_^_'$COLOR6'_
/^7/s_^_'$COLOR7'_
'  /proc/kmsg /dev/tty

place whole that perl shit on initrams of your kernel, run it in
background as early as possible with switched off default console output
(i.e. quiet boot).

OVER.

For really good output it would be better to have escape code to
serialize printing, thus no coloring brain damage will appear in
concurrent writes on the tty (multiple areas, cursor movements). And this
is only start of what can be done here.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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_^_'$COLOR1'_
 /^2/s_^_'$COLOR2'_
 /^3/s_^_'$COLOR3'_
 /^4/s_^_'$COLOR4'_
 /^5/s_^_'$COLOR5'_
 /^6/s_^_'$COLOR6'_
 /^7/s_^_'$COLOR7'_
 '  /proc/kmsg /dev/tty
 
 place whole that perl shit on initrams of your kernel, run it in
 background as early as possible with switched off default console output
 (i.e. quiet boot).
 
 OVER.
 
 Speaking of over, this does not fly at all. If you call panic(),
 for whatever reason you want, then the printk() is the last thing
 that happens after that, you can declare userspace dead.
 On oopses, it depends on their severity. Eventually procfs goes
 whoops and the kmsg transmission mechanism does not work, and oh,
 userspace can't help it.

I can rephrase/repeat: Here's discussion about general usage and feature
set.

The Development/debugging of the kernel, especially early boot or hard
core OOPs isn't covered. If a kernel developer wants to have nice looking
OOPes, i bet, this has nothing to do with general purpose printk() and
loglevels and the kernel, that usually must boot once, until next
security update.

This is just another debugging tool, that could be written faster than
any of the fancy rewrites of the kernel's core. Written many many
years ago with much reacher coloring features.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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) == '<' &&
> LOG_BUF(cur_index + 1) >= '0' &&
> LOG_BUF(cur_index + 1) <= '7' &&
> LOG_BUF(cur_index + 2) == '>') {
> msg_level = LOG_BUF(cur_index + 1) - '0';
> cur_index += 3;
> start_print = cur_index;
> }
> 
> >I mean, *write() have nothing to do with loglevels. If they do
> >(suddenly), then why not to use a char in the *str to make it possible? I
> >might be wrong, but there are already macros before format strings in
> >printk().
> >
> >And this is not `loglevel' thing any more. It's attributes, which can be
> >used by many other drivers/file systems/schedulers/ what ever, if
> >developers, like Ingo, will extend printk() output to be more nice in
> >subsystems they develop.
> 
> If I interpret you correctly, you want me to remove cur_index+=3
> and instead reparse  in drivers/char/vt.c. But that's not good,
> because if you use serial, we won't go to vt.c, and in the end,
> 8250.c would also need to parse , which I think is just walking
> around the hill.

I thought, i was talking about *write() functions, that got one
additional unrelated, non config removable API change in face of
`unsigned int loglevel'.

Idea. Extend those macro defines before format string with one
additional macro, that will be empty, if config is NO and having
colour byte otherwise.

In the *write() functions, have

 color = str[0];
 ++str;

in case if config is YES. And nothing otherwise.


Sorry, i don't know much about stuff, you've presented:

> kernel/printk.c -> 8250.c -> grab_loglevel_from_string -> ignore it and print
> message
> kernel/printk.c -> vt.c -> grab_loglevel_from_string -> print color according
> to loglevel

so maybe i just am an ignorant. Anyway this:

> VS
> 
> kernel/printk.c -> pass loglevel directly to 8250.c -> ignore loglevel and
> print message
> kernel/printk.c -> pass loglevel directly to vt.c -> print color according to
> loglevel

have no compile or run time optimization possible.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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' approach is more important for me.
> > > 
> > > There is noone having trouble with ncurses dependency today.
> > 
> > Who wants to meet a zombie anyway?
> 
> Finding quotes from old threads does not in any way prove your point.

This makes air hot for Roman. I want to prove my point not by words. But
have to reply with something on my side, until i have work done.

[]
> And until now you have not given one single example of real
> problems that will be solved by a total rewrite and cannot
> be solved otherwise.

If you didn't see them in that, what i've posted, then i just have to
say: i don't need to give anything. There are kvm, lguest, xen with ext2,
ext3, xfs, etc. And there's no working alternative to build/config
system. Thus, let me have my try OK? Thanks!

Bye.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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, 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 to express opinion quickly and easily?
> 
> You can't. I think that people will usually be interested _why_ you
> voted for or against something

Do you really think so? Yes, there are possibly LKML bots, that will
read all messages in every thread. But i doubt they are humans.

I also think, that kill-files and kill-names are common tools of the LKML
readers. Thus, if someone sees my name with something like NAK in the
subject, then nothing to worry about: next, please. I just amazed how
inefficiently Subject, To, Cc headers are used. Everybody hurry through
huge mail backlogs with subjects in thread all like one.

Summary and keywords headers are not used, so why not to make
greping/selecting interesting/useful messages more efficient (and not
only for those who is in Cc list)?

Every mail/news reader displays To and Subject, so latter is last hope of
increasing of efficiency, even in small threads.

> (given the number of vote-submitters does not go through the roof).
> That clearly won't fit into the subject,

Sorry, i cannot see, what you are trying to say here. To place all
acks-by to subject? No, just to get summary in one particular reply.

> and even if RFC822 allowed it, it's only displayed like 40 chars wide.
> The submitter (me in this case) will even look at *all* mails, so as to
> (1) address the NAKs and (2) address the hidden feature requests in
> ACKs.  :-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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= or by modifying
> the sysfs file in the running system.
> 
> Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
> 
> ---
>  arch/x86_64/kernel/early_printk.c |   11 +++
>  drivers/char/Kconfig  |4 +++-
>  drivers/char/vt.c |   32 
>  drivers/net/netconsole.c  |3 ++-
>  drivers/serial/8250.c |3 ++-
>  drivers/serial/8250_early.c   |3 ++-
>  include/linux/console.h   |2 +-
>  kernel/printk.c   |   12 +++-
>  8 files changed, 48 insertions(+), 22 deletions(-)

Making this amount changes and not thinking about more intelligent
coding of the functionality?

> Index: linux-2.6.23/arch/x86_64/kernel/early_printk.c
> ===
> --- linux-2.6.23.orig/arch/x86_64/kernel/early_printk.c
> +++ linux-2.6.23/arch/x86_64/kernel/early_printk.c
> @@ -20,7 +20,8 @@
>  static int max_ypos = 25, max_xpos = 80;
>  static int current_ypos = 25, current_xpos = 0;
>  
> -static void early_vga_write(struct console *con, const char *str, unsigned n)
> +static void early_vga_write(struct console *con, const char *str, unsigned n,
> +unsigned int loglevel)
>  {

I mean, *write() have nothing to do with loglevels. If they do
(suddenly), then why not to use a char in the *str to make it possible? I
might be wrong, but there are already macros before format strings in
printk().

And this is not `loglevel' thing any more. It's attributes, which can be
used by many other drivers/file systems/schedulers/ what ever, if
developers, like Ingo, will extend printk() output to be more nice in
subsystems they develop.

So, maybe they can be extended, and functionality implemented in the
function bodies (which will be `do { } while (0)' if config is NO), but
*NOT* by passing additional argument to the functions.
___
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

On Sat, Oct 06, 2007 at 09:48:20PM +0200, Ingo Molnar wrote:
> > 
> > This is a "kernel messages color-l10n".
> > 
> > * text code size, that cannot be zero if config option is not set;
> 
> not really an issue. Changing the inline function to non-inline will get 
> rid of most of the text cost. Embedded wont build in a console.

I'm trying to say "text size *and* config option is not set". That
have nothing to do with other text size reductions.

> > * completely useless, if properly implemented in userspace (with much
> >   reacher functionality).
> 
> that's hogwash. No user-space runs during early bootup. (and yes i want 
> a color code at glance if something hangs in early bootup) Nothing will 
> color-code crashes, etc., etc. Control of the _kernel_ console by 
> user-space is complete nonsense.

If it is so important for major kernel developer like you, Ingo, then
why there's no scrollback at first place? Why nothing like that was
not implemented up until now?   

My first ever Linux hack was changing default console output color. I
think it was seven years ago. I though, it was not serious, if nobody
did that already (in the 2.2.14).

Please, don't mix important stuff here. I know, what kernel console is.

> The kernel console is one of the most important information channels of
> the kernel towards the user.

I'd say: towards hard OOPs-handling developer.

> this is nice and 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
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 to express opinion quickly and easily?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 anyway?

== Message-ID: <[EMAIL PROTECTED]> ==
From: Petr Baudis
Subject: [PATCH 3/3] [kconfig] Direct use of lxdialog routines by menuconfig
Date: Mon, 12 Dec 2005 01:46:06 +0100

After three years, the zombie walks again!  This patch (against the latest
git tree) cleans up interaction between kconfig's mconf (menuconfig
frontend) and lxdialog. Its commandline interface disappears in this patch,
instead a .so is packed from the lxdialog objects and the relevant
functions are called directly from mconf.

== * ==

> And perl is not yet mandatory for a kernel build expect
> for a few architectures.

Not build per se, but perl mind share of the people. Did they ever
looked into `strace`, when running (kind of) `perl simple-regex`?

Maybe there weren't right people to manage things easily in shell?
Reinventing parser was a major step back, whatever anyone can say.

== (seems like not original ID) [EMAIL PROTECTED] ==
From: Sam Ravnborg
Subject: Get rid of shell based Config.in parsers?
Date: Wed, 14 Aug 2002 22:14:00 +0200

[...]

I dislike seeing arguments that this is not easy/possible in shell based
parsers. If the chosen technology does not fit the problem domain
then it's about time to shift technology.

Sam
== * ==

== Message-ID: <[EMAIL PROTECTED]> ==
From: Linus Torvalds
Subject: Re: Get rid of shell based Config.in parsers?
Date: Thu, 15 Aug 2002 10:51:03 -0700 (PDT)

On Wed, 14 Aug 2002, Sam Ravnborg wrote:
>
> Where comes the requirement that we shall keep the existing shell
> based config parsers?

I use them exclusively.

It is far and away the most convenient parsing - just to do "make
oldconfig"  (possibly by making changes by hand to the .config file
first).

As far as I'm personally concerned, the shell parsers are the _only_
parser that really matter. So if you want to replace them with something
else, that something else had better be pretty much perfect and not take
all that long to build.

Linus
== * ==

> m4 is not used by the kernel - to my best knowledge.

That was a rhetoric (i guess) statement. But it *is* used to
configure/build almost all tools, currently directly or indirectly
kbuild/kconfig uses.

`m4 'make "shell"'`

*OR*

`To quote lguest 'To quote David Wheeler:

"Any problem in computer science can be solved with
 another layer of indirection."'`

That's my personal view. And after 5-6 years of the "development", i
can see the "results". Again, will see.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Cute feature: colored printk output

[Oleg Verych]

* 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? Then write so, please.

>> which helps to distinguish it from other noise, such as boot messages.
>> NetBSD has it, OpenBSD has it, FreeBSD to some extent, so I think
>> Linux should too.

This approach in GIGO-like, IMHO. Ugliness of (default) boot process
messaging itself can and must be solved in the userspace. I don't know if
anybody read sub-thread about size reduction by moving static printk
string to userspace "message codes" (there were one more person than me,
but still).

The main problem, is the very narrow perspective of such "kernel"
functionality:

> feature request: would be interesting to have a color table (defined in 
> the .config) dependent on message loglevel. That way KERN_CRIT messages 
> could be red, KERN_INFO ones white, etc.
>
>   Ingo

See? In the userspace one can make anything freely, try do it in the
Linux kernel. With userspace {codes, messages} -> messages tool, any
console printing frontend is possible. Of course, when kernel OOPes
before or in early userspace, where nothing other than photo viva is
possible, nobody should care about "Linux's cuteness!"

>> Inspired by cko (http://freshmeat.net/p/cko/), but independently
>> written, later contributed forth and back.
>> 
>> Already posted at: http://lkml.org/lkml/2007/4/1/162
>> 
>> Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
>
> looks really good to me!
>
> Reviewed-by: Ingo Molnar <[EMAIL PROTECTED]>
>
> small nit:
>
> +   vc->vc_color = printk_color;
> +   update_attr(vc);
>
> that should be in a set_vc_color() function and the new code should do:
>
> + set_vc_color(vc, vc->vc_color);
>
> (and same at the other places that call update_attr() as well)

Is it possible to have a macro for this, which will be
`do { } while(0)' in case of "NO, thanks" configuration?

--
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 (the rewrite).
> 
> Qutie frankly, this kind of "I'll tell you more when I'm done" is not 
> generally a very working approach. 
> 
> If it's all backwards-compatible with the current Kconfig format, I guess 
> it's not too bad, but historically speaking, the people who went off on 
> their own and redesigned something from scratch have not been successful 
> (and the CML2 thing is a good example of that).

Spent whole September on LKML archive (grave) digging, actually. So,
please, get me right.

If i have finally made statement like that (rewrite with new design),
that basically means, i'll try to bring something, that probably will be
better, not emotionally (CML2 :), but technically (kbuild-2.5's 100%
slowdown of some important functionality :).

> Incremental improvements actually tend to do better than "redesign".  

I'm not going to call (and thus targeting) that thing "kbuild-2.7" or
"kconfig-ng", "CML3000" or anything like that.

If my proposal will fit, i.e. configuring and building something
(anything) becomes more easy, more flexible, etc., then any project can
try and adopt it actually. And this will be a measure of quality.

> That's largely true outside of computer science too..

Will see. If i will fail, who will care; i will not. Somebody spend years
of doing that, what was rejected. More than 5 years of current
kbuild/kconfig "development calmness". So...

Maintenance and acceptance of the m4/make/perl/C/ncurses community of my
mainly `TERM=linux ; sed && sh' approach is more important for me.

Thanks, Linus.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 such statements, you have to offer a little more than 
> the hot air you're producing right now...
...

> If you want to improve the design, you're more than welcome. I'm the first 
> one to admit that there's still lots of room for improvement, but if you 
> want to claim this can only be done via a rewrite, then you have to be 
> a lot more specific what's wrong the current design and why it's 
> unfixable.
> Quite some thought has been put into this design and if you were a little 
> more specific, I could actually tell you why it is this way and maybe how 
> to improve it incrementally instead of trying to reinvent everything.

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 (the rewrite).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 such statements, you have to offer a little more than 
 the hot air you're producing right now...
...

 If you want to improve the design, you're more than welcome. I'm the first 
 one to admit that there's still lots of room for improvement, but if you 
 want to claim this can only be done via a rewrite, then you have to be 
 a lot more specific what's wrong the current design and why it's 
 unfixable.
 Quite some thought has been put into this design and if you were a little 
 more specific, I could actually tell you why it is this way and maybe how 
 to improve it incrementally instead of trying to reinvent everything.

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 (the rewrite).

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 (the rewrite).
 
 Qutie frankly, this kind of I'll tell you more when I'm done is not 
 generally a very working approach. 
 
 If it's all backwards-compatible with the current Kconfig format, I guess 
 it's not too bad, but historically speaking, the people who went off on 
 their own and redesigned something from scratch have not been successful 
 (and the CML2 thing is a good example of that).

Spent whole September on LKML archive (grave) digging, actually. So,
please, get me right.

If i have finally made statement like that (rewrite with new design),
that basically means, i'll try to bring something, that probably will be
better, not emotionally (CML2 :), but technically (kbuild-2.5's 100%
slowdown of some important functionality :).

 Incremental improvements actually tend to do better than redesign.  

I'm not going to call (and thus targeting) that thing kbuild-2.7 or
kconfig-ng, CML3000 or anything like that.

If my proposal will fit, i.e. configuring and building something
(anything) becomes more easy, more flexible, etc., then any project can
try and adopt it actually. And this will be a measure of quality.

 That's largely true outside of computer science too..

Will see. If i will fail, who will care; i will not. Somebody spend years
of doing that, what was rejected. More than 5 years of current
kbuild/kconfig development calmness. So...

Maintenance and acceptance of the m4/make/perl/C/ncurses community of my
mainly `TERM=linux ; sed  sh' approach is more important for me.

Thanks, Linus.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Cute feature: colored printk output

[Oleg Verych]

* 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? Then write so, please.

 which helps to distinguish it from other noise, such as boot messages.
 NetBSD has it, OpenBSD has it, FreeBSD to some extent, so I think
 Linux should too.

This approach in GIGO-like, IMHO. Ugliness of (default) boot process
messaging itself can and must be solved in the userspace. I don't know if
anybody read sub-thread about size reduction by moving static printk
string to userspace message codes (there were one more person than me,
but still).

The main problem, is the very narrow perspective of such kernel
functionality:

 feature request: would be interesting to have a color table (defined in 
 the .config) dependent on message loglevel. That way KERN_CRIT messages 
 could be red, KERN_INFO ones white, etc.

   Ingo

See? In the userspace one can make anything freely, try do it in the
Linux kernel. With userspace {codes, messages} - messages tool, any
console printing frontend is possible. Of course, when kernel OOPes
before or in early userspace, where nothing other than photo viva is
possible, nobody should care about Linux's cuteness!

 Inspired by cko (http://freshmeat.net/p/cko/), but independently
 written, later contributed forth and back.
 
 Already posted at: http://lkml.org/lkml/2007/4/1/162
 
 Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

 looks really good to me!

 Reviewed-by: Ingo Molnar [EMAIL PROTECTED]

 small nit:

 +   vc-vc_color = printk_color;
 +   update_attr(vc);

 that should be in a set_vc_color() function and the new code should do:

 + set_vc_color(vc, vc-vc_color);

 (and same at the other places that call update_attr() as well)

Is it possible to have a macro for this, which will be
`do { } while(0)' in case of NO, thanks configuration?

--
-o--=O`C
 #oo'L O
___=E M
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 anyway?

== Message-ID: [EMAIL PROTECTED] ==
From: Petr Baudis
Subject: [PATCH 3/3] [kconfig] Direct use of lxdialog routines by menuconfig
Date: Mon, 12 Dec 2005 01:46:06 +0100

After three years, the zombie walks again!  This patch (against the latest
git tree) cleans up interaction between kconfig's mconf (menuconfig
frontend) and lxdialog. Its commandline interface disappears in this patch,
instead a .so is packed from the lxdialog objects and the relevant
functions are called directly from mconf.

== * ==

 And perl is not yet mandatory for a kernel build expect
 for a few architectures.

Not build per se, but perl mind share of the people. Did they ever
looked into `strace`, when running (kind of) `perl simple-regex`?

Maybe there weren't right people to manage things easily in shell?
Reinventing parser was a major step back, whatever anyone can say.

== (seems like not original ID) [EMAIL PROTECTED] ==
From: Sam Ravnborg
Subject: Get rid of shell based Config.in parsers?
Date: Wed, 14 Aug 2002 22:14:00 +0200

[...]

I dislike seeing arguments that this is not easy/possible in shell based
parsers. If the chosen technology does not fit the problem domain
then it's about time to shift technology.

Sam
== * ==

== Message-ID: [EMAIL PROTECTED] ==
From: Linus Torvalds
Subject: Re: Get rid of shell based Config.in parsers?
Date: Thu, 15 Aug 2002 10:51:03 -0700 (PDT)

On Wed, 14 Aug 2002, Sam Ravnborg wrote:

 Where comes the requirement that we shall keep the existing shell
 based config parsers?

I use them exclusively.

It is far and away the most convenient parsing - just to do make
oldconfig  (possibly by making changes by hand to the .config file
first).

As far as I'm personally concerned, the shell parsers are the _only_
parser that really matter. So if you want to replace them with something
else, that something else had better be pretty much perfect and not take
all that long to build.

Linus
== * ==

 m4 is not used by the kernel - to my best knowledge.

That was a rhetoric (i guess) statement. But it *is* used to
configure/build almost all tools, currently directly or indirectly
kbuild/kconfig uses.

`m4 'make shell'`

*OR*

`To quote lguest 'To quote David Wheeler:

Any problem in computer science can be solved with
 another layer of indirection.'`

That's my personal view. And after 5-6 years of the development, i
can see the results. Again, will see.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

On Sat, Oct 06, 2007 at 09:48:20PM +0200, Ingo Molnar wrote:
  
  This is a kernel messages color-l10n.
  
  * text code size, that cannot be zero if config option is not set;
 
 not really an issue. Changing the inline function to non-inline will get 
 rid of most of the text cost. Embedded wont build in a console.

I'm trying to say text size *and* config option is not set. That
have nothing to do with other text size reductions.

  * completely useless, if properly implemented in userspace (with much
reacher functionality).
 
 that's hogwash. No user-space runs during early bootup. (and yes i want 
 a color code at glance if something hangs in early bootup) Nothing will 
 color-code crashes, etc., etc. Control of the _kernel_ console by 
 user-space is complete nonsense.

If it is so important for major kernel developer like you, Ingo, then
why there's no scrollback at first place? Why nothing like that was
not implemented up until now?   

My first ever Linux hack was changing default console output color. I
think it was seven years ago. I though, it was not serious, if nobody
did that already (in the 2.2.14).

Please, don't mix important stuff here. I know, what kernel console is.

 The kernel console is one of the most important information channels of
 the kernel towards the user.

I'd say: towards hard OOPs-handling developer.

 this is nice and 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
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 to express opinion quickly and easily?

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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= or by modifying
 the sysfs file in the running system.
 
 Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
 
 ---
  arch/x86_64/kernel/early_printk.c |   11 +++
  drivers/char/Kconfig  |4 +++-
  drivers/char/vt.c |   32 
  drivers/net/netconsole.c  |3 ++-
  drivers/serial/8250.c |3 ++-
  drivers/serial/8250_early.c   |3 ++-
  include/linux/console.h   |2 +-
  kernel/printk.c   |   12 +++-
  8 files changed, 48 insertions(+), 22 deletions(-)

Making this amount changes and not thinking about more intelligent
coding of the functionality?

 Index: linux-2.6.23/arch/x86_64/kernel/early_printk.c
 ===
 --- linux-2.6.23.orig/arch/x86_64/kernel/early_printk.c
 +++ linux-2.6.23/arch/x86_64/kernel/early_printk.c
 @@ -20,7 +20,8 @@
  static int max_ypos = 25, max_xpos = 80;
  static int current_ypos = 25, current_xpos = 0;
  
 -static void early_vga_write(struct console *con, const char *str, unsigned n)
 +static void early_vga_write(struct console *con, const char *str, unsigned n,
 +unsigned int loglevel)
  {

I mean, *write() have nothing to do with loglevels. If they do
(suddenly), then why not to use a char in the *str to make it possible? I
might be wrong, but there are already macros before format strings in
printk().

And this is not `loglevel' thing any more. It's attributes, which can be
used by many other drivers/file systems/schedulers/ what ever, if
developers, like Ingo, will extend printk() output to be more nice in
subsystems they develop.

So, maybe they can be extended, and functionality implemented in the
function bodies (which will be `do { } while (0)' if config is NO), but
*NOT* by passing additional argument to the functions.
___
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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, 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 to express opinion quickly and easily?
 
 You can't. I think that people will usually be interested _why_ you
 voted for or against something

Do you really think so? Yes, there are possibly LKML bots, that will
read all messages in every thread. But i doubt they are humans.

I also think, that kill-files and kill-names are common tools of the LKML
readers. Thus, if someone sees my name with something like NAK in the
subject, then nothing to worry about: next, please. I just amazed how
inefficiently Subject, To, Cc headers are used. Everybody hurry through
huge mail backlogs with subjects in thread all like one.

Summary and keywords headers are not used, so why not to make
greping/selecting interesting/useful messages more efficient (and not
only for those who is in Cc list)?

Every mail/news reader displays To and Subject, so latter is last hope of
increasing of efficiency, even in small threads.

 (given the number of vote-submitters does not go through the roof).
 That clearly won't fit into the subject,

Sorry, i cannot see, what you are trying to say here. To place all
acks-by to subject? No, just to get summary in one particular reply.

 and even if RFC822 allowed it, it's only displayed like 40 chars wide.
 The submitter (me in this case) will even look at *all* mails, so as to
 (1) address the NAKs and (2) address the hidden feature requests in
 ACKs.  :-)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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' approach is more important for me.
   
   There is noone having trouble with ncurses dependency today.
  
  Who wants to meet a zombie anyway?
 
 Finding quotes from old threads does not in any way prove your point.

This makes air hot for Roman. I want to prove my point not by words. But
have to reply with something on my side, until i have work done.

[]
 And until now you have not given one single example of real
 problems that will be solved by a total rewrite and cannot
 be solved otherwise.

If you didn't see them in that, what i've posted, then i just have to
say: i don't need to give anything. There are kvm, lguest, xen with ext2,
ext3, xfs, etc. And there's no working alternative to build/config
system. Thus, let me have my try OK? Thanks!

Bye.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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) == '' 
 LOG_BUF(cur_index + 1) = '0' 
 LOG_BUF(cur_index + 1) = '7' 
 LOG_BUF(cur_index + 2) == '') {
 msg_level = LOG_BUF(cur_index + 1) - '0';
 cur_index += 3;
 start_print = cur_index;
 }
 
 I mean, *write() have nothing to do with loglevels. If they do
 (suddenly), then why not to use a char in the *str to make it possible? I
 might be wrong, but there are already macros before format strings in
 printk().
 
 And this is not `loglevel' thing any more. It's attributes, which can be
 used by many other drivers/file systems/schedulers/ what ever, if
 developers, like Ingo, will extend printk() output to be more nice in
 subsystems they develop.
 
 If I interpret you correctly, you want me to remove cur_index+=3
 and instead reparse N in drivers/char/vt.c. But that's not good,
 because if you use serial, we won't go to vt.c, and in the end,
 8250.c would also need to parse N, which I think is just walking
 around the hill.

I thought, i was talking about *write() functions, that got one
additional unrelated, non config removable API change in face of
`unsigned int loglevel'.

Idea. Extend those macro defines before format string with one
additional macro, that will be empty, if config is NO and having
colour byte otherwise.

In the *write() functions, have

 color = str[0];
 ++str;

in case if config is YES. And nothing otherwise.


Sorry, i don't know much about stuff, you've presented:

 kernel/printk.c - 8250.c - grab_loglevel_from_string - ignore it and print
 message
 kernel/printk.c - vt.c - grab_loglevel_from_string - print color according
 to loglevel

so maybe i just am an ignorant. Anyway this:

 VS
 
 kernel/printk.c - pass loglevel directly to 8250.c - ignore loglevel and
 print message
 kernel/printk.c - pass loglevel directly to vt.c - print color according to
 loglevel

have no compile or run time optimization possible.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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 turning on new items, and the ability to deselect options which will
>> > > also confirm to deselect dependants. Like most other systems that have
>> > > similar problem to solve.
>> >
>> > Actually, the *really* nice thing to do would be to just add the reason
>> > something got enabled into the ".config" file.
[]
>> >CONFIG_ACPI=y   # selected by X86_64_ACPI_NUMA
>> >CONFIG_ACPI_PROCFS=y# user choice
>> >...
[]
>> Sure, that would probably be pretty trivial to implement too, and
>> would solve most problems for kernel devs.
>> 
>> At a level up from that, I think ease of use could be improved with
>> a package manager-type chained-selection/deselection feature in
>> the config tools.
>> 
>> Not that I'm volunteering to implement either ;)
>> 
>> >
>> > That way, there's always a fairly straightforward way to see why some
>> > configuration is the way it is (and the .config file is not only useful
>> > for "make oldconfig", it's also what normally gets passed around for bug
>> > reports, and is part of distro kernel packages etc, so it would seem to be
>> > the right place, no?)
>> >
>> >Linus
[]
> Adding the comments to the .config files sounds like a good project for a 
> comparative newbie. By the end of next week I should have hardware available 
> for experimental kernel builds. (And also some free wetware cycles.) 
>
> Are there any other requirements for formatting I should consider? 

No. Not another semi-newbie and/or semi-halfway done job, please.

I'm pretty sure, that Linus is proposing that only after manual
editing of/looking into the `.config' after `make oldconfig`.

Before you will consider anything, please, check recent LKML (kbuild
rewrite) and kbuild-devel(years 2001-2002) archives (assuming, you have
experience with any build/conf things).

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).

The basics, i'm trying to put into design of the new kconfig, as part of
my kbuild (already described a bit)/kconfig rewrite are:

* flexible configuration development(kdevs) and process(kusers)

  + shell-like[0] (not like CML1, which is just shell) scripting, allowing
to extend easily (if there is no one available) capabilities,
config values or actions for particular sub-system or compilation
unit,

  [0] if somebody would like to see *a* shell-like scripting:
  ftp://flower.upol.cz/geloiwa/src/usr/local/etc/geloiwa/iwant

  + duplex travelling, multi- looking at/changing of config items,

  + flexible, yet built-able, connections in dependency chain (tree,
graph, whatever);

* resulting config file capable of producing exact config results of the
  build on any other setup
  (e.g. no ARCH=, CROSS_*, *_FLAGS *kbuild* things);

* checking tool for particular config patterns (for bug reports)

* system itself must be done with minimum requirements for C libraries
  (no ncurses) and tools (no `perl`, no `python`, no `make`).

> In a case where option A is specified by option B which is specified by 
> option 
> C which is specified by option D, should the comment on A mention B, or D or 
> all three items in the chain? 

Fsck it. All must be done by a machine with maximum comfort of users (not
particularly humans), even for those, who like to edit config like so:

`sed -i 's/SYSFS=y/SYSFS="please, NO!!!"/' .config`

--
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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 turning on new items, and the ability to deselect options which will
   also confirm to deselect dependants. Like most other systems that have
   similar problem to solve.
 
  Actually, the *really* nice thing to do would be to just add the reason
  something got enabled into the .config file.
[]
 CONFIG_ACPI=y   # selected by X86_64_ACPI_NUMA
 CONFIG_ACPI_PROCFS=y# user choice
 ...
[]
 Sure, that would probably be pretty trivial to implement too, and
 would solve most problems for kernel devs.
 
 At a level up from that, I think ease of use could be improved with
 a package manager-type chained-selection/deselection feature in
 the config tools.
 
 Not that I'm volunteering to implement either ;)
 
 
  That way, there's always a fairly straightforward way to see why some
  configuration is the way it is (and the .config file is not only useful
  for make oldconfig, it's also what normally gets passed around for bug
  reports, and is part of distro kernel packages etc, so it would seem to be
  the right place, no?)
 
 Linus
[]
 Adding the comments to the .config files sounds like a good project for a 
 comparative newbie. By the end of next week I should have hardware available 
 for experimental kernel builds. (And also some free wetware cycles.) 

 Are there any other requirements for formatting I should consider? 

No. Not another semi-newbie and/or semi-halfway done job, please.

I'm pretty sure, that Linus is proposing that only after manual
editing of/looking into the `.config' after `make oldconfig`.

Before you will consider anything, please, check recent LKML (kbuild
rewrite) and kbuild-devel(years 2001-2002) archives (assuming, you have
experience with any build/conf things).

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).

The basics, i'm trying to put into design of the new kconfig, as part of
my kbuild (already described a bit)/kconfig rewrite are:

* flexible configuration development(kdevs) and process(kusers)

  + shell-like[0] (not like CML1, which is just shell) scripting, allowing
to extend easily (if there is no one available) capabilities,
config values or actions for particular sub-system or compilation
unit,

  [0] if somebody would like to see *a* shell-like scripting:
  ftp://flower.upol.cz/geloiwa/src/usr/local/etc/geloiwa/iwant

  + duplex travelling, multi- looking at/changing of config items,

  + flexible, yet built-able, connections in dependency chain (tree,
graph, whatever);

* resulting config file capable of producing exact config results of the
  build on any other setup
  (e.g. no ARCH=, CROSS_*, *_FLAGS *kbuild* things);

* checking tool for particular config patterns (for bug reports)

* system itself must be done with minimum requirements for C libraries
  (no ncurses) and tools (no `perl`, no `python`, no `make`).

 In a case where option A is specified by option B which is specified by 
 option 
 C which is specified by option D, should the comment on A mention B, or D or 
 all three items in the chain? 

Fsck it. All must be done by a machine with maximum comfort of users (not
particularly humans), even for those, who like to edit config like so:

`sed -i 's/SYSFS=y/SYSFS=please, NO!!!/' .config`

--
-o--=O`C
 #oo'L O
___=E M
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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;
> > >   unsigned long long size = -1;
> > 
> > no need in assigning values here, unless you plan to use them in case
> > of `return -EINVAL', but i can not see that,
> 
> What about this (and yes, I tested with some wrong strings with Qemu):

Reviewed-by: Oleg Verych <[EMAIL PROTECTED]>

Thanks :D

> 
> 
> This patch improves error handling in parse_crashkernel_mem() by comparing
> the return pointer of memparse() with the input pointer and also replaces
> all printk(KERN_WARNING msg) with pr_warning(msg).
> 
> 
> Signed-off-by: Bernhard Walle <[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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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.
>> 
>> Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
>>
>
> No, network devices don't do reference counting.

Could you explain why, please?

After `udevd` on boot loads lots of unused crap, i surrendered, and use
$(rmmod `lsmod | just first column`). Networing bravely wipes away. OK,
there are lots of configs: udev, hotplug, modprobe, that somebody might
like to fix. But it came to the end with me. I just don't care. So,
please answer :)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 function
(ULL from str) have always return value grater or equal to zero.

Thus,

> 
> Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
> 
> ---
>  kernel/kexec.c |   31 ---
>  1 file changed, 24 insertions(+), 7 deletions(-)
> 
> --- 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;
>   unsigned long long size = -1;

no need in assigning values here, unless you plan to use them in case
of `return -EINVAL', but i can not see that,

> + char *tmp;
>  
>   /* get the start of the range */
> - start = memparse(cur, );
> + start = memparse(cur, );
> + if (cur == tmp) {
> + pr_warning("crashkernel: Memory value expected\n");
> + return -EINVAL;
> + }
> + cur = tmp;
>   if (*cur != '-') {
> - printk(KERN_WARNING "crashkernel: '-' expected\n");
> + pr_warning("crashkernel: '-' expected\n");
>   return -EINVAL;
>   }
>   cur++;
>  
>   /* if no ':' is here, than we read the end */
>   if (*cur != ':') {
> - end = memparse(cur, );
> + end = memparse(cur, );
> + if (cur == tmp) {
> + pr_warning("crashkernel: Memory "
> + "value expected\n");
> + return -EINVAL;
> + }
> + cur = tmp;
>   if (end <= start) {
> - printk(KERN_WARNING "crashkernel: end <= 
> start\n");
> + pr_warning("crashkernel: end <= start\n");
>   return -EINVAL;
>   }
>   }
>  
>   if (*cur != ':') {
> - printk(KERN_WARNING "crashkernel: ':' expected\n");
> + pr_warning("crashkernel: ':' expected\n");
>   return -EINVAL;
>   }
>   cur++;
>  
> - size = memparse(cur, );
> + size = memparse(cur, );
> + if (cur == tmp) {
> + pr_warning("Memory value expected\n");
> + return -EINVAL;
> + }
> + cur = tmp;
>   if (size < 0) {

`size' cannot be less that zero here (wonder, if it matters to have
userspace model of this parser and actually feed it with garbage input).

> - printk(KERN_WARNING "crashkernel: invalid size\n");
> + pr_warning("crashkernel: invalid size\n");
>   return -EINVAL;
>   }
>  


Wed, Sep 26, 2007 at 06:16:02PM +0200, Bernhard Walle (part one):
> Ok, that's fixed now, see patch below.
> 
> > And why not to make overall result reliable? This is kernel after all.
> > 
> > I.e. if there's valid `crashkernel=' option, but some parsing errors, why
> > not to apply some heuristics with warning in syslog, if user have some
> > conf, bootloader (random) errors, but feature still works?
> 
> I'm against guessing. The user has to specify a parameter which is
> right according to syntax.
> 
> However, I plan to make a patch that the kernel can detect a sensible
> offset automatically for i386 and x86_64 as it's done in ia64. Since
> both architectures have a relocatable kernel now, that makes perfectly
> sense. But that's another patch.

I was thinking about errors in YaST or typos in bootloader config, that
may appear sometimes. And kernel must tolerate this kind of userspace
input to be more reliable. But you know better, i just am waving hands.

("Mail-Followup-To:" respected)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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
(ULL from str) have always return value grater or equal to zero.

Thus,

 
 Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
 
 ---
  kernel/kexec.c |   31 ---
  1 file changed, 24 insertions(+), 7 deletions(-)
 
 --- 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;
   unsigned long long size = -1;

no need in assigning values here, unless you plan to use them in case
of `return -EINVAL', but i can not see that,

 + char *tmp;
  
   /* get the start of the range */
 - start = memparse(cur, cur);
 + start = memparse(cur, tmp);
 + if (cur == tmp) {
 + pr_warning(crashkernel: Memory value expected\n);
 + return -EINVAL;
 + }
 + cur = tmp;
   if (*cur != '-') {
 - printk(KERN_WARNING crashkernel: '-' expected\n);
 + pr_warning(crashkernel: '-' expected\n);
   return -EINVAL;
   }
   cur++;
  
   /* if no ':' is here, than we read the end */
   if (*cur != ':') {
 - end = memparse(cur, cur);
 + end = memparse(cur, tmp);
 + if (cur == tmp) {
 + pr_warning(crashkernel: Memory 
 + value expected\n);
 + return -EINVAL;
 + }
 + cur = tmp;
   if (end = start) {
 - printk(KERN_WARNING crashkernel: end = 
 start\n);
 + pr_warning(crashkernel: end = start\n);
   return -EINVAL;
   }
   }
  
   if (*cur != ':') {
 - printk(KERN_WARNING crashkernel: ':' expected\n);
 + pr_warning(crashkernel: ':' expected\n);
   return -EINVAL;
   }
   cur++;
  
 - size = memparse(cur, cur);
 + size = memparse(cur, tmp);
 + if (cur == tmp) {
 + pr_warning(Memory value expected\n);
 + return -EINVAL;
 + }
 + cur = tmp;
   if (size  0) {

`size' cannot be less that zero here (wonder, if it matters to have
userspace model of this parser and actually feed it with garbage input).

 - printk(KERN_WARNING crashkernel: invalid size\n);
 + pr_warning(crashkernel: invalid size\n);
   return -EINVAL;
   }
  


Wed, Sep 26, 2007 at 06:16:02PM +0200, Bernhard Walle (part one):
 Ok, that's fixed now, see patch below.
 
  And why not to make overall result reliable? This is kernel after all.
  
  I.e. if there's valid `crashkernel=' option, but some parsing errors, why
  not to apply some heuristics with warning in syslog, if user have some
  conf, bootloader (random) errors, but feature still works?
 
 I'm against guessing. The user has to specify a parameter which is
 right according to syntax.
 
 However, I plan to make a patch that the kernel can detect a sensible
 offset automatically for i386 and x86_64 as it's done in ia64. Since
 both architectures have a relocatable kernel now, that makes perfectly
 sense. But that's another patch.

I was thinking about errors in YaST or typos in bootloader config, that
may appear sometimes. And kernel must tolerate this kind of userspace
input to be more reliable. But you know better, i just am waving hands.

(Mail-Followup-To: respected)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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.
 
 Signed-off-by: Jan Beulich [EMAIL PROTECTED]


 No, network devices don't do reference counting.

Could you explain why, please?

After `udevd` on boot loads lots of unused crap, i surrendered, and use
$(rmmod `lsmod | just first column`). Networing bravely wipes away. OK,
there are lots of configs: udev, hotplug, modprobe, that somebody might
like to fix. But it came to the end with me. I just don't care. So,
please answer :)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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;
 unsigned long long size = -1;
  
  no need in assigning values here, unless you plan to use them in case
  of `return -EINVAL', but i can not see that,
 
 What about this (and yes, I tested with some wrong strings with Qemu):

Reviewed-by: Oleg Verych [EMAIL PROTECTED]

Thanks :D

 
 
 This patch improves error handling in parse_crashkernel_mem() by comparing
 the return pointer of memparse() with the input pointer and also replaces
 all printk(KERN_WARNING msg) with pr_warning(msg).
 
 
 Signed-off-by: Bernhard Walle [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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 3/5] Add samples subdir

[Oleg Verych]

* 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 in all arch/ Kconfigs.
>
> Sorry for not commenting on this before...
> The samples directory contains sample code so it is wrong to actually
> include it as part of the kernel IMHO.

Count my HO too.

Kernel isn't school desk at first place. It's already bloated as with
various 2+y obsolete changelogs (that have content, that even older),
with unsorted documentation (hypertext and http are better on this).

Up to date test cases and example code must be on developer's site,
not as burden in the sources. Yea, linux tar ball is a popular one.
But sorry, it already has too much unneeded stuff for most of the
freelance users and testers. This tarball must have good end result
with propper changelogs and pointers to *fresh* information.
--
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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 it.
[]
> +++ b/include/linux/kexec.h
> @@ -187,6 +187,8 @@ extern u32 vmcoreinfo_note[VMCOREINFO_NO
>  extern size_t vmcoreinfo_size;
>  extern size_t vmcoreinfo_max_size;
>  
> +int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
> + unsigned long long *crash_size, unsigned long long *crash_base);

I still want to point out my consernes about `unsigned long long long'
bloat.

>  #else /* !CONFIG_KEXEC */
>  struct pt_regs;
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
[]
> +/*
> + * This function parses command lines in the format
> + *
> + *   crashkernel=:[,...][@]

#v+
[EMAIL PROTECTED]:/tmp$ grep '@offset' :[,:,[EMAIL PROTECTED]
-   /* [EMAIL PROTECTED] specifies the size to reserve for a crash
+While the "[EMAIL PROTECTED]" syntax is sufficient for most
+crashkernel=:[,:,[EMAIL PROTECTED]
+   crashkernel=range1:size1[,range2:size2,[EMAIL PROTECTED]
[EMAIL PROTECTED]:/tmp$ grep '@base' :[,...][@]
[EMAIL PROTECTED]:/tmp$ grep '@ + *
> + * The function returns 0 on success and -EINVAL on failure.
> + */
> +static int __init parse_crashkernel_mem(char 
> *cmdline,
> + unsigned long long  system_ram,
> + unsigned long long  *crash_size,
> + unsigned long long  *crash_base)
> +{
> + char *cur = cmdline;
> +
> + /* for each entry of the comma-separated list */
> + do {
> + unsigned long long start = 0, end = ULLONG_MAX;
> + unsigned long long size = -1;

memparse(), as a wrapper for somple_strtoll(), always have a return value
(zero by default).


Consider coded error path now, please.

And why not to make overall result reliable? This is kernel after all.

I.e. if there's valid `crashkernel=' option, but some parsing errors, why
not to apply some heuristics with warning in syslog, if user have some
conf, bootloader (random) errors, but feature still works?

> +
> + /* get the start of the range */
> + start = memparse(cur, );
> + if (*cur != '-') {
> + printk(KERN_WARNING "crashkernel: '-' expected\n");
> + return -EINVAL;
> + }
> + cur++;
> +
> + /* if no ':' is here, than we read the end */
> + if (*cur != ':') {
> + end = memparse(cur, );
> + if (end <= start) {
> + printk(KERN_WARNING "crashkernel: end <= 
> start\n");
> + return -EINVAL;
> + }
> + }
> +
> + if (*cur != ':') {
> + printk(KERN_WARNING "crashkernel: ':' expected\n");
> + return -EINVAL;
> + }
> + cur++;
> +
> + size = memparse(cur, );
> + if (size < 0) {
> + printk(KERN_WARNING "crashkernel: invalid size\n");
> + return -EINVAL;
> + }
> +
> + /* match ? */
> + if (system_ram >= start  && system_ram <= end) {
> + *crash_size = size;
> + break;
> + }
> + } while (*cur++ == ',');
> +
> + if (*crash_size > 0) {
> + while (*cur != ' ' && *cur != '@')
> + cur++;
> + if (*cur == '@')
> + *crash_base = memparse(cur+1, );
> + }
> +
> + return 0;
> +}
--
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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 it.
[]
 +++ b/include/linux/kexec.h
 @@ -187,6 +187,8 @@ extern u32 vmcoreinfo_note[VMCOREINFO_NO
  extern size_t vmcoreinfo_size;
  extern size_t vmcoreinfo_max_size;
  
 +int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
 + unsigned long long *crash_size, unsigned long long *crash_base);

I still want to point out my consernes about `unsigned long long long'
bloat.

  #else /* !CONFIG_KEXEC */
  struct pt_regs;
 --- a/kernel/kexec.c
 +++ b/kernel/kexec.c
[]
 +/*
 + * This function parses command lines in the format
 + *
 + *   crashkernel=ramsize-range:size[,...][@base]

#v+
[EMAIL PROTECTED]:/tmp$ grep '@offset' extended-crashkernel-cmdline.mbox
crashkernel=range1:size1[,range2:size2,[EMAIL PROTECTED]
-   /* [EMAIL PROTECTED] specifies the size to reserve for a crash
+While the [EMAIL PROTECTED] syntax is sufficient for most
+crashkernel=range1:size1[,range2:size2,[EMAIL PROTECTED]
+   crashkernel=range1:size1[,range2:size2,[EMAIL PROTECTED]
[EMAIL PROTECTED]:/tmp$ grep '@base' extended-crashkernel-cmdline.mbox
+ * [EMAIL PROTECTED]
[EMAIL PROTECTED]:/tmp$ grep '@base' extended-crashkernel-cmdline.mbox
+ *   crashkernel=ramsize-range:size[,...][@base]
[EMAIL PROTECTED]:/tmp$ grep '@offset' extended-crashkernel-cmdline.mbox
[EMAIL PROTECTED]:/tmp$
#v-

 + *
 + * The function returns 0 on success and -EINVAL on failure.
 + */
 +static int __init parse_crashkernel_mem(char 
 *cmdline,
 + unsigned long long  system_ram,
 + unsigned long long  *crash_size,
 + unsigned long long  *crash_base)
 +{
 + char *cur = cmdline;
 +
 + /* for each entry of the comma-separated list */
 + do {
 + unsigned long long start = 0, end = ULLONG_MAX;
 + unsigned long long size = -1;

memparse(), as a wrapper for somple_strtoll(), always have a return value
(zero by default).
http://article.gmane.org/gmane.linux.kernel/583426

Consider coded error path now, please.

And why not to make overall result reliable? This is kernel after all.

I.e. if there's valid `crashkernel=' option, but some parsing errors, why
not to apply some heuristics with warning in syslog, if user have some
conf, bootloader (random) errors, but feature still works?

 +
 + /* get the start of the range */
 + start = memparse(cur, cur);
 + if (*cur != '-') {
 + printk(KERN_WARNING crashkernel: '-' expected\n);
 + return -EINVAL;
 + }
 + cur++;
 +
 + /* if no ':' is here, than we read the end */
 + if (*cur != ':') {
 + end = memparse(cur, cur);
 + if (end = start) {
 + printk(KERN_WARNING crashkernel: end = 
 start\n);
 + return -EINVAL;
 + }
 + }
 +
 + if (*cur != ':') {
 + printk(KERN_WARNING crashkernel: ':' expected\n);
 + return -EINVAL;
 + }
 + cur++;
 +
 + size = memparse(cur, cur);
 + if (size  0) {
 + printk(KERN_WARNING crashkernel: invalid size\n);
 + return -EINVAL;
 + }
 +
 + /* match ? */
 + if (system_ram = start   system_ram = end) {
 + *crash_size = size;
 + break;
 + }
 + } while (*cur++ == ',');
 +
 + if (*crash_size  0) {
 + while (*cur != ' '  *cur != '@')
 + cur++;
 + if (*cur == '@')
 + *crash_base = memparse(cur+1, cur);
 + }
 +
 + return 0;
 +}
--
-o--=O`C
 #oo'L O
___=E M
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 3/5] Add samples subdir

[Oleg Verych]

* 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 in all arch/ Kconfigs.

 Sorry for not commenting on this before...
 The samples directory contains sample code so it is wrong to actually
 include it as part of the kernel IMHO.

Count my HO too.

Kernel isn't school desk at first place. It's already bloated as with
various 2+y obsolete changelogs (that have content, that even older),
with unsorted documentation (hypertext and http are better on this).

Up to date test cases and example code must be on developer's site,
not as burden in the sources. Yea, linux tar ball is a popular one.
But sorry, it already has too much unneeded stuff for most of the
freelance users and testers. This tarball must have good end result
with propper changelogs and pointers to *fresh* information.
--
-o--=O`C
 #oo'L O
___=E M
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc7 + radeonfb/s2ram

[Oleg Verych]

* 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 radeonfb for me :( at least, not now; but I have to be 
> honest with
>   you: I don't see what commit dd1447134454b169d5ae353aceb93f2368db8547 
> brought new
>   into the picture. The previous radeonfb worked just great, but then, again, 
> maybe I'm
>   not using the console at it's full power :)

In fact, it's known statement, that there must only one hardware driver
for graphic adapter. Be it framebuffer with X fb driver on it or legacy
VGA text and X with its driver.so and 3D stuff.

(i choose legacy text without X for the most of my time, though :)
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

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 extend linux/lib/cmdline.c->{get_range(), 
get_range()}
to handle that stuff? And maybe new functionality can be built up-on the 
current one: 

- crashkernel=512M-2G:64M,2G-:[EMAIL PROTECTED]
+ crashkernel=512M-2G,64M,2G-,128M,,offset
?

OK, OK, you are already using and maintaining new syntax, but still.
_
(`Mail-Followup-To' ignored)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Oleg Verych]

* 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 calls to "memparse" which have
> no use for the value returned in the second parameter (the current
> pointer after the successful parse), but which are still forced to
> supply a valid char** address since they have no choice but to accept
> that value coming back.  in many cases, that value is accepted just
> before the end of the calling function, making it clear that the value
> is ignored entirely, anyway.

A posteriori value, stored in this pointer serves very important role: it
validates returned result. Caller must do this. But if programmer doesn't
know problems (see below), `must' melts down to `may'.

If you take a look at simple_strtoull(), it already doesn't care if this
pointer is NULL or not. (So patch is NULL :)

But take closer look. If it returns `0' (zero), it is not clear if this
zero was parsed or not, unless you can compare `ptr' and `retptr'.
Another case if entire string have no valid number to parse (see
strtol(3)).

This is problem of this particular function, that is copied form
ordinary C. For instance see .
--
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unfortunate infinite make recursion

[Oleg Verych]

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 binutils, kbuild, root user bugs won't garbage source. Only thing
> > to ask from experienced users *and* kernel developers, is
> > `useradd kbuild`, everything else will not bother anybody.
> Better would be to fix the bugs where we today clobber the sources.
> Care to point out the exact cases you see.

It is not about particular case, it is about whole environment.

* interactive:
shell (profile setup).--> source editing / patching
  `-> building parts / doing tests

where profile is one particular source tree with particular
config/development goals. On multiple terminals (sessions), one
may just type in favorite shell `wana profile-xx` and environment
is set up there. I.e.

+ where ever you are, it's easy to go to current obj or src tree,
+ quilt knows its setup
+ kbuild does also
+ tracking files, sent to editor (e.g. emacsclient / emacsserver)
  o easily composing file / change sets to be operated by quilt
  o kbuild knows exactly what to check and possibly to rebuild
+ all actions are written to history, that can be imported into any session
  o saving sessions
  o restore sessions: checking profile consistency / updating
+ less ugly (e.g. just stupid bash command line) user interface
  o even ordinary command line can be improved much-much more in
terms of efficiency and comfort
  o more nice-looking information of what is happening and how is
happening

* automatic:
running setup of selected profiles:
o patch/update sources
o configure and (cross) build multiple source trees with multiple output
  trees each.
o run time testing: emulators, hardware.

Many ideas, collected in kbuild-2.5-history.tar.bz2 back in 2000, are
still interesting and useful.

More i do development, more i realize, that i spend too much time to
do trivial and repeating things. And this time will not go less, if
something like that will be by hand.

I'd really like to see a work flow of best development staff, because
behind patches i can not see anything. And frankly, i doubt there's
anything significant there. The only sharing of tools i can see is
patch scripts (now quilt), diff-tools, linux/scripts. Still just tools.

There's no environment, where people would know particular configs for
editors, mailers, 2-3 steps easy to get right help messages, i.e
*environment*. UI tricks, like common, most useful, sh aliases for using
tools, different color schemas: for error/log output, editing C or asm
(with linux specific annotations, rules), tools like checkpatch, but not
checkpatch -- helper for developers to get changes checked and ready to
create actual patch, etc. etc. etc

For example, i'd really like to have, candy C + diff color fontlocking
(emacs' brain damaged lexicon) for easy patch reviewing. I did some
trivial enhancements more than 3 years ago, like highlighting of actions
that change variable's value, thus, i don't do many stupid things in C any
more. I'd like to have candy fontlocking for sed and shell and
sed-in-shell syntax, etc. etc.

And all this is needed just for stupid terminal emulator. So, what
people are doing all this time? Noo, X? There's no X, period.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/