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]

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 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] 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/

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/

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&um=1&hl=cs&client=firefox-a&rls=org.mozilla%3Acs%3Aofficial&q=I+will+use+Google+before&btnG=Hledat+obr%C3%A1zky
... for making translations..."
http://www.google.com/translate?u=http%3A%2F%2Flxr.linux.no%2Flinux%2FDocumentation%2FHOWTO&langpair=en%7Czh-TW&hl=en&ie=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/

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&um=1&hl=cs&client=firefox-a&rls=org.mozilla%3Acs%3Aofficial&q=I+will+use+Google+before&btnG=Hledat+obr%C3%A1zky
> >... for making translations..."
> >http://www.google.com/translate?u=http%3A%2F%2Flxr.linux.no%2Flinux%2FDocumentation%2FHOWTO&langpair=en%7Czh-TW&hl=en&ie=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: 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  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: [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 subjec

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/

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=&

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: 

-
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: [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." 

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: 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: 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 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: - lguest-the-asm-offsets.patch removed from -mm tree

[Oleg Verych]

> This is the structure offsets required by lg.ko's switcher.S.
>
> Unfortunately we don't have infrastructure for private asm-offsets
> creation.

I did asm-offsets build rewrite RFC caled asm-values more than four week
ago: 

Just FYI.

-
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/

asm-offsets

[Oleg Verych]

On Fri, Jul 20, 2007 at 11:34:13AM +1000, Rusty Russell wrote:
> On Thu, 2007-07-19 at 23:46 +0200, Oleg Verych wrote:
> > > This is the structure offsets required by lg.ko's switcher.S.
> > >
> > > Unfortunately we don't have infrastructure for private asm-offsets
> > > creation.
> > 
> > I did asm-offsets build rewrite RFC caled asm-values more than four week
> > ago: <http://mid.gmane.org/[EMAIL PROTECTED]>
> 
> Indeed, but you're poking the wrong person.  Sam needs to ack or fwd...

Even busy people can say something about proposed design of that
rewrite, so work will not stall like this. But lost message is another
case of course.

Patches were spit with one being example of application for lguest.

Thus i did group reply to that merged patch after reading its log :)


-
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: asm-offsets

[Oleg Verych]

On Fri, Jul 20, 2007 at 01:23:40PM +1000, Rusty Russell wrote:
>   I appreciate your frustration!

It isn't, just a conversation, everyone can skip, you know.

> Unfortunately I'm not fluent enough in kbuild to be able to give
> meaningful commentary,

Modest Rusty :)

> so pinging Sam is my way of helping this along...

Thanks for doing this, because apart from being more readable i've found
that for example dummy arch/sparc64/kernel/asm-offsets.c may benefit from
it as well.

-
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] run scripts/Lindent on it to match Documentation/CodingStyle

[Oleg Verych]

* Date: Fri, 20 Jul 2007 11:07:43 -0600

> Of course, we can't add this flag to Lindent until it's widely
> circulating amongst the distributions.  Perhaps we can add this to
> Lindent in the meantime:
>
> sed -i -e 's/^\t*  \(\w*:\)/ \1/' "$@"
>
> which will replace the leading tabs and spaces with one space.
> It should leave case labels unmolested, as they should be indented with
> tabs, not 6 spaces.
>
> Any regexp ninjas want to have a go at something better?

I'm the one. Trying to write portable, optimized and easy to
understand scripts [0].

Please, describe more what must be done, and i will do it. Case labels
are handled very strangely in you example.

[0] <[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/

Fixing lables after GNU indent (Re: [PATCH 1/2] run scripts/Lindent on it to match Documentation/CodingStyle)

[Oleg Verych]

[]
> > > sed -i -e 's/^\t*  \(\w*:\)/ \1/' "$@"
> > >
> > > which will replace the leading tabs and spaces with one space.
> > > It should leave case labels unmolested, as they should be indented with
> > > tabs, not 6 spaces.
> > >
> > > Any regexp ninjas want to have a go at something better?
> > 
> > I'm the one. Trying to write portable, optimized and easy to
> > understand scripts [0].
> > 
> > Please, describe more what must be done, and i will do it. Case labels
> > are handled very strangely in you example.
> 
> OK.  indent will indent labels to a column number that's a multiple of
> 8, plus 6.  So it may start in column 6, 14, 20, 28, etc.  I'm not quite
> sure what the definition of a label is; I had it as \w*: up there, but I
> don't know if that would match the _.  The point is to *not* handle case
> labels, only goto labels.

t=`printf '\t'`
sed -i "s_^\($t*\)  *\([^:]*:\)_\1\2_" "$@"
  ^-_
I'm not sure about leaving one space `here, otherwise it removes
spaces between (supposedly right indented) line start, i.e. nothing or
tab(s), and a label, i.e. `label_name:' without space before colon;
`label_name' here actually not a colon, let's leave that kind of
breakage to compiler.

The variable $t is used for readability of the regex and because POSIX
BREs leave undefined characters after a backslash, POSIX sed defines
only \n as a new line.

--
-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 25/33] kbuild: use POSIX BRE in headers install target

[Oleg Verych]

* Date: Tue, 17 Jul 2007 16:08:54 +0200
>
> From: Mike Frysinger <[EMAIL PROTECTED]>
>
> The sed expression used at the moment in scripts/Makefile.headersinst
> relies on the (handy) GNU extension where you can escape ERE's in an
> otherwise BRE without using the GNU -r option.  The following patch
> replaces this "\+" usage with a functionally equivalent POSIX BRE compliant
> "\{1,\}".

Matching at least one occurrence, right?

> Tested with `make headers_install` against blackfin/x86_64/i386
> targets.
>
> Stupid whiny OS X users and their crappy sed ;)

That may be. My games with strict POSIX sed syntax render busybox's sed
as crap for example. So, you never know.

>  # Eliminate the contents of (and inclusions of) compiler.h

OK, that means annotations and non ANSI 'inline' thing. Lets see.

>  HDRSED  := sed   -e "s/ inline / __inline__ /g" \
[]
> - -e "s/[[:space:]]__attribute_const__[[:space:]]\+/\ /g" \

* [[:space:]] are more than tab and space isspace(3), is it more
  effective to use [[:blank:]] instead?

> + -e 
> "s/[[:space:]]__user[[:space:]]\{1,\}

substitute one or more ' __user '

> / /g" \

with ' ', everywhere (flag 'g'). So, is it really needed that '\{' thing?

> + -e "s/(__user[[:space:]]\{1,\}/ (/g" \
> + -e "s/[[:space:]]__force[[:space:]]\{1,\}/ /g" \
> + -e "s/(__force[[:space:]]\{1,\}/ (/g" \
> + -e "s/[[:space:]]__iomem[[:space:]]\{1,\}/ /g" \
> + -e "s/(__iomem[[:space:]]\{1,\}/ (/g" \
> + -e "s/[[:space:]]__attribute_const__[[:space:]]\{1,\}/\ /g" \
>   -e "s/[[:space:]]__attribute_const__$$//" \

Is it allowed to use identifiers like '__attribute_const__foo' or
__attribute_const__[anything]? If it's not, last line is useless also.

>   -e "/^\#include /d"
whitespace is allowed   ^ here and is used for better readability
sometimes.

-
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 25/33] kbuild: use POSIX BRE in headers install target

[Oleg Verych]

On Sat, Jul 21, 2007 at 10:23:44AM +0200, Andreas Schwab wrote:
> Oleg Verych <[EMAIL PROTECTED]> writes:
> 
> >> +  -e 
> >> "s/[[:space:]]__user[[:space:]]\{1,\}
> >
> > substitute one or more ' __user '
> 
> Substitute ' __user' followed by one or more ' '.  \{\} applies only to
> the last RE atom.

Right, that's why i've used '  *' sometimes.

Thanks.

> Andreas.
> 

-
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: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target

[Oleg Verych]

On Sat, Jul 21, 2007 at 04:27:31AM -0400, Mike Frysinger wrote:
[] 
> if you want to make some micro optimization in the build install step,
> sure ... but functionally, the difference is irrelevant considering
> sed operates only on individual lines

That was an attempt to support less sucking userspace in the kernel
development. More readable, more memory/cpu effective, more portable.

-
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: Patches for REALLY TINY 386 kernels

[Oleg Verych]

* Date: Wed, 18 Jul 2007 12:00:05 -0700

>> If this is an issue, then changing i386 back to discarding __exit code 
>> and data at linktime instead of runtime might make a bigger difference.
>
> What would really make a big difference would be to unspool the
> initramfs in such a way that it only requires O(1) instead off O(n)
> extra memory, by freeing memory as it decompresses and decodes the cpio
> ball.

Why it's not done yet, your opinion?

>   -hpa

-
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/

More effective processing (Re: [PATCH 25/33] kbuild: use POSIX BRE in headers install target)

[Oleg Verych]

On Sat, Jul 21, 2007 at 10:39:16PM +0200, Sam Ravnborg wrote:
> On Sat, Jul 21, 2007 at 03:21:43PM -0400, Mike Frysinger wrote:
[]
> > while you could try and make a claim against memory/cpu effeciency, i
> > fail to see how the first or last claims could possibly be backed up

Less \{\(\\n\t\+\)\} [0] stuff make readings regex much easier. My
confusion shows that i didn't used \{ much, because have another ways
so far. And even after my quick testing i didn't realize that there
was unrelated to main task whitespace cleanup.

[0] http://sed.sf.net/grabbag/tutorials/lookup_tables.txt

> > but again, if you feel that strongly about it, you're certainly free
> > to post a patch
> 
> I would much more prefer this functionality to be integrated into unifdef.
> There is no good reason to have two different preprocesisng methonds, one
> being the sed based one and the other the unidef one.

Clear definition of the task will help to design a solution. I can do
the job, but figuring out all possible corner cases from current
solutions, mixed in Makefiles or everywhere else is not option.

> A sinlge dedicated program that contian the sum of the functionality would
> be faster too.

What do you think about this one? I want to propose to remove
scripts/unifdef.c but to make clear policy about how to mark __KERNEL__
sections in header files. We know how obfuscated C can be, and this also
applies to preprocessing. There's known CodingStyle about some points.
The thing is to specify rules, that will be easy for `sed` to do cleaup
job.

./linux/soundcard.h:#if (!defined(__KERNEL__) && !defined(KERNEL) && 
!defined(INKERNEL)
  && !defined(_KERNEL)) || defined(USE_SEQ_MACROS)
./linux/stat.h:#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)

Split __KERNEL__ check, make only positive, i.e.

#if defined(__KERNEL__)
#ifdef __KERNEL__

./linux/stat.h:#ifdef __KERNEL__

No `#else` and ending part to contain comment:

./linux/smb_fs_sb.h:#endif /* __KERNEL__ */

Simple enough:

sed '/^#if[^_]*__KERNEL__/,/^#end[^_]*__KERNEL__/d'

-
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, Announce] Unified x86 architecture, arch/x86

[Oleg Verych]

* From: Alan Cox
* Date: Sat, 21 Jul 2007 00:55:12 +0100
* Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, 
Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a 
Lloegr o'r rhif cofrestru 3798903
>
> On Fri, 20 Jul 2007 18:38:39 -0400
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
>> I agree with Andi...  it's quite nice to be able to leave some arch/i386 
>> stuff, and not carry it over to arch/x86-64.
>
> Its easy enough to push that stuff into arch/x86/legacy and have one
> subdirectory of stuff to pull in for ancient systems.

Or if i386 and virualization guys don't want to quietly break/mess with
stuff pulled by x86-64, move it to x86-64 instead. Elegant, easy, honors
Andi.

-
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: More effective processing (Re: [PATCH 25/33] kbuild: use POSIX BRE in headers install target)

[Oleg Verych]

On Sun, Jul 22, 2007 at 12:13:26AM +0200, Sam Ravnborg wrote:
> On Sun, Jul 22, 2007 at 12:16:27AM +0200, Oleg Verych wrote:
> > 
> > What do you think about this one? I want to propose to remove
> > scripts/unifdef.c but to make clear policy about how to mark __KERNEL__
> > sections in header files. We know how obfuscated C can be, and this also
> > applies to preprocessing. There's known CodingStyle about some points.
> > The thing is to specify rules, that will be easy for `sed` to do cleaup
> > job.
> > 
> > ./linux/soundcard.h:#if (!defined(__KERNEL__) && !defined(KERNEL) && 
> > !defined(INKERNEL)
> >   && !defined(_KERNEL)) || defined(USE_SEQ_MACROS)
> > ./linux/stat.h:#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ 
> > < 2)
> > 
> > Split __KERNEL__ check, make only positive, i.e.
> > 
> > #if defined(__KERNEL__)
> > #ifdef __KERNEL__
> > 
> > ./linux/stat.h:#ifdef __KERNEL__
> > 
> > No `#else` and ending part to contain comment:
> > 
> > ./linux/smb_fs_sb.h:#endif /* __KERNEL__ */
> > 
> > Simple enough:
> > 
> > sed '/^#if[^_]*__KERNEL__/,/^#end[^_]*__KERNEL__/d'
> 
> What are you trying to say with the above?
> Sorry but I lost track of part of the discussion but you seems to havea point 
> here?

I want to suggest more easy and tools-friendly way of processing header
files in the headrer_install target. One line above, one paragraph in
CodingStyle, one tree revision from KJ group.

-
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] [9/58] x86_64: Always use builtin memcpy on gcc 4.3

[Oleg Verych]

* From: Andi Kleen <[EMAIL PROTECTED]>
* Date: Thu, 19 Jul 2007 11:54:53 +0200 (CEST)
>
> Jan asked to always use the builtin memcpy on gcc 4.3 mainline because
> it should generate better code than the old macro. Let's try it.

Unfortunately such info is hard to find. The [EMAIL PROTECTED] list is
empty. So, let me ask how this memcpy relates to recently submitted
for glibc one [0]?

[0] 

Also you are enabling rep. string operations for 10h family. Yet manual
says, that while they were improved, there are still various other
preferred optimization cases

Thanks.

> Cc: [EMAIL PROTECTED]
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
>
> ---
>  include/asm-x86_64/string.h |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

-
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] asus-laptop: ASUS laptop no longer compiles. I think this is the right fix ?

[Oleg Verych]

* Date: Mon, 23 Jul 2007 14:53:10 +0100

http://permalink.gmane.org/gmane.linux.kernel/559360

-
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: Documentation files in html format?

[Oleg Verych]

* Date: Fri, 10 Aug 2007 09:40:47 +0200
* Sam Ravnborg:
>
> Documentation should be easy to access and readable in the source format.
> For this purpose asciidoc seems to do a good job.
>
> It is btw. discussed at git ML if they should shift due to toolset being
> slow but that happens to be the docbook utilities. asciidoc seems to be fast 
> enough.
> And it can produce both HTML and docbook so seems to cover all cases.

just plain text

another option: txt2tags && sed

For me anything else, like man, info, (xml, html)+css, is a brain
damage. If it's fine for you -- it's your wasted time and mood.

(yet another big useless thread on useless OT, how sad).

-
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: about modularization

[Oleg Verych]

* Date: Fri, 3 Aug 2007 15:19:00 +0200
* Received-SPF: softfail (mx3: transitioning domain of elte.hu does not 
designate 157.181.1.14 as permitted sender) client-ip=157.181.1.14; [EMAIL 
PROTECTED]; helo=elvis.elte.hu;

> If you boot into a distro kernel on 
> a typical PC, about half of the kernel code that the box runs in any 
> moment will be in modules, half of it is in the "kernel core". For 
> example, on a random laptop:

That was your laptop and distro.

>  $ echo `lsmod | cut -c1-30 | cut -d' ' -f2-` | sed 's/Size //' |
>sed 's/ /+/g' | bc
>  2513784
>
> i.e. 2.5 MB of modules. The core kernel's size:
>
>  $ dmesg | grep 'kernel code'
>  Memory: 2053212k/2087808k available (2185k kernel code, 33240k reserved, 
> 1174k data, 244k init, 1170304k highmem)
>
> 2.1 MB of kernel core code. (of course the total body of "possible 
> drivers" is 10 times larger than that of the core kernel - but the 
> fundamental 'variety' is not.)

Just for reference here's my 2+ years old Asus A4K, kernel is form
Debian Etch:

deen:/tmp# uname -a
Linux deen 2.6.18-4-amd64 #1 SMP Mon Mar 26 11:36:53 CEST 2007 x86_64 x86_64
deen:/tmp# lsmod | (read a; while read a b c; do S=$((b+${S=0})); done; echo $S)
1583684
deen:/tmp# lsmod | grep xfs
xfs   485192  3
deen:/tmp# dmesg | grep kernel\ code   
Memory: 506676k/523520k available (1930k kernel code, 16456k reserved, 868k 
data, 176k init)

Apart from diff in hardware and implied designing/coding skills, decision
was made

* after one "wrong" response plus illness from Con,
* brave core-duo by Ingo and Tomas, who made some bunch of students to test
  scheduler and reported success to Linus.

I don't know why, after all that variety of things (mostly drivers, but
recent *fd also) there's such big resistance to anything that's useful
and used by ordinary people. A star sickness, pride? If yes, that's just
ridiculous, but who cares.

-
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: Thinking outside the box on file systems

[Oleg Verych]

* Date: Sun, 19 Aug 2007 03:57:58 +0100

>> don't forget the ACPI interpreter.
>
> YAProof that bogons follow Boze statistics...

or bugons, then.

Why big minds didn't do rdev-like binary patching of the kernel image
with binary ACPI data? Getting such data in (any) userspace would be the
only thing in the install process of a modern distro, otherwise it's just
a boring decompressing with copying.

-
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/

kconfig/kbuild rewite (Re: What's up with CONFIG_BLK_DEV?)

[Oleg Verych]

* Sun, 26 Aug 2007 01:08:28 -0500
* Organization: Boundaries Unlimited
>
[]
> Also "here's a symbol, show me a menu containing everything else that is 
> either required by or enabled by this symbol..."  That sounds like a more 
> powerful abstraction, since the previous one is "show me everything that 
> depends on CONFIG_BLOCK".
>
> (I wonder if this would be a largeish rewrite of the menuconfig 
> infrastructure?  Hmmm...)

Yess. I'm doing this, actually. Sam, Andrew and Linus have got an email
half a year ago about my intent. Tried to release 2.6.20-j4f, but that
was just a dream. Now i did some training in non-kernel related stuff and
always catch (30k, 14k) LKML backlogs to stay in tune. Some bits i 
get are here ftp://flower.upol.cz/Linux/info-LKML/tools/

So, ideas: UI, organization, efficiency, simplicity, etc. are welcome.

Maybe in one month i'll get something to show (base is 2.6.22).
Imagination plays very well, the thing must be ground shaking, but i'll
see how it will fit reality. Yours one in consideration from very
beginning, don't bother :)

Another problem that i have to solve before any publishing (it's
completely another tree, logic, interface), is the work tracking system,
i was describing in June. This is important, because i sick of current
chaos and manual organizing work in-tree or in regression tracking.

-
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: [OT] good job guys with the anti-spam !

[Oleg Verych]

* Tue, 31 Jul 2007 23:40:11 +0200
>
[]
> eventhough people often write only when they have something to complain
> about, I for once would like to congratulate Matti and David, our mail
> admins, for the wonderful job they've done with the spams lately. This
> month, I might have seen maybe one or two instead of perhaps 30 per day
> earlier. While it did not bother me that much earlier, I can say that
> the list is more pleasant to read every day, and I think that's great.
>
> Kudos guys !
>
> Willy
>
> PS: please do not start another one of those long useless threads from now on
>

Instead let me share an idea and see what will happen (if any).
The mailing list policy:

1. sent mails must have in-reply-to (rfc2821 SHOULD) with valid, i.e.
   existing in archives, message-id;

2. otherwise sender gets response about creating new thread. Replying
   to that message will enable (1).

I don't know how performance of ever increasing anti-spam
rules/software grow vs message-id lookup will be affected.

Gmane shows good performance on load, which is times bigger than LKML's.
News server requires unique ids, so...

Ah, if spammers will become smart and will reply with appropriate headers
set up, everything will fall apart.

Finally. What i see:
* no spam,
* big patch-bombs in one thread (easy to skip)
* more order, if useless/obsolete footers removed, but such info is
  sent in (2).

* easy blacklisting if rules are not obeyed since day X

  Oh, no, don't say we value bug reports. Reports must be organized in
  other way, one of which i've described as development tracking system.
  Such e-mail policy is unavoidable part of this it. E-mail is everything
  it requires. Of course some html, css, javascript, perl guys will be
  free to implement any web-face they like. But story if git-web have
  something to learn instead.
--
-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: [ANNOUNCE] seekwatcher v0.3 IO graphing an animation

[Oleg Verych]

* Fri, 27 Jul 2007 21:20:57 -0400
>
[]
> Here's a sample of the smoother graphs (creating 20 kernel trees):
>
> http://oss.oracle.com/~mason/seekwatcher/ext3_vs_btrfs_vs_xfs.png

It seems, that making log for XFS on different physical device can
boost performance. Will it be reliable, is a question, isn't it?

-
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: [OT] good job guys with the anti-spam !

[Oleg Verych]

On Sun, Sep 02, 2007 at 02:39:36AM +0200, Bj?rn Steinbrink wrote:
[]
> 
> Ehrm, you want everyone who wants to start a new thread to:
> 
>  - send an email
>  - await response from the mail server
>  - send the same email again as a reply to the first one

No. Send a ticket request and then organize patch bomb with gotten ticket
in `references:' or `in-reply-to'. New discussion thread: be organized
have a pull of tickets, care about what you post, how you post, etc.

Those new posters will get current footer with more info -- no problem.

People in thread need no work at all. Linus, Andrew, Jeff, DaveM etc.
are likely to be in white list with no additional work also.

It's anti-spam thing, but maybe it can be kind of netiquette, which is
forgotten in modern XML Internet world. I didn't live in that time, but
that's my impression. In case if efficient algo/logic will be implemented
it will save CPU power, because all processing is done in header part of
the message and it's a token lookup. Switch on your imagination and
think, what can be done in another way, why not? 

-
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: [OT] good job guys with the anti-spam !

[Oleg Verych]

On Sun, Sep 02, 2007 at 10:18:36AM +0200, Willy Tarreau wrote:
[]
>
> Your method

as i mentioned

> makes it trivial for them to request 1 ticket, then send 1 mails
> which will be accepted without ever being filtered. It will result in
> an increase of the number of spams and a great annoyance for the users.

It's metter of experiment to know how much spammers today

* compose messages with non outloock default headers

* have *valid* reply address
  ** if it's valid and message to get ticket looks spammy as well as message
 after ticket does, address gets blacklisted forever

* bother about published email address' policy

> Not for me, thanks :-/

You know, after requests like "we need more man power to handle mail
lists" i wonder in what century we are leaving XXI or IIX?

OTHO Gmane is an excellent example of applying NNTP structure, that is
very superior to mailing lists concept. But as i mentioned, i don't know
whole story about USENET vs Mailing lists. I just speculate, that latter
was established as an private entity, that groups of people can handle as
they need and want.

But NNTP isn't USENET, and only Gmane shows how it lets people like me to
handle tens of thousand emails in nearly 60 mailing lists (not only
reading up to date, but archives easily). And frankly, i just pissed off
by "6 day lkml archive, please", "Adrian, your email is bouncing, bla
bla...". I'd better see spam, then dumb things like that, 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: GPL weasels and the atheros stink

[Oleg Verych]

* Sun, 2 Sep 2007 16:03:07 +0200
>
> Hi. My name may not ring a bell for lots of lklm members.

Hallo, Marc. It's OK; shit happens, calm down, please.

[]
> Well, if that's truely the case, I may reconsider my good faith for future
> contributions. Heck, instead of giving away my code under the GPL, I could
> keep my contributions in the form of patches. Ironically, with tools such
> as git, this is no longer as cumbersome as this used to be. So, instead
> of new gcc code sent to the FSF (and given to the FSF), we could explicitly
> keep patches under the ISC licence, and explain loudly why this is so.

About GCC this is a good point. Seconded. Maybe then `sparse' by Linus
and friends will be a good competitor for that FSF guarded pet...

[]
> Nice going, GPL fan-boys...

HA-ha. Shit hits the fan-boys.

GPL is not FSF. GPL or FSF is not Debian. Linux is (was?) for FUN.

Good bye.
--
-o--=O`C  info emacs-manual : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not foundo  (  yes --- R.I.P. FSF + RMS)
<___=E M  man gcc: not found  `--  ( viva Debian Operating System )
-
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: kconfig/kbuild rewite (Re: What's up with CONFIG_BLK_DEV?)

[Oleg Verych]

On Sun, Sep 02, 2007 at 01:51:50PM +0200, Sam Ravnborg wrote:
[]
> Then as now you have not yet expalined what you are trying to do.
> Nevertheless I look forward for a minmal set of patches that improve
> whatever you are working with.

Yes, because it's LKML, that wants not-hand-waving stuff in first
place. But recent kevent, scheduler stuff shows
inflexibility/agendas, though.

That examples were bad WRT kernel production infrastructure. Even then i
doubt, i must waste everyone's time with details, only goals.

> As for Kconfig the low hanging fruits are not in the tools but in the
> structure of the Kconfig files. There are a lot that can be improved
> with a decent effort but nobody has stepped up doing so.
> The tools could be better too but if the root problem is the structure
> of the Kconfig files this is where we should focus and not on the tools.

In my view this all interconnected. Designing flexible and easy
configuration system yields dramatic changes to the build one as well.

* profiles non/debug, non/production

* per file, per algorithm tuning
  * efficiency
* choosing structure sizes
* selecting fast/slow paths
* per case choosing need/dead code
* various parameters
  * optimization
* per compiler/version
  * option profiles
  * feature/warning sets
* linker
  * is there anything alternative?

* distributed development
  * open possibility to work in any part of the tree
* making changes and quickly having
  * config (dependency, etc.) set/UI ready
  * per profile/option test builds
(e.g. making return->goto or loop change and quickly getting -O0,
-O2, -Os images; check size; have userspace testing skeleton -> have
runtime test)
* integration with quilt-like source/patch managers ``here''
  * allow per architecture development
* small source tree
* developer's profiles, that will have exact feature/tuning/build
  config options results for everybody within given source tree version
  (for easy testing, but not "send me your .config; what binutils?..")

* base set of tools to have easy to configure alternatives
  * shell
to use basic POSIX (plus accepted, not NIH like in bash) features
(i have some examples; unfortunately even basic set behaves
 differently and buggy)
  * make
stat() wrapper executing shell everywhere; of course there are
some features, but anyway, interface for it and the like is needed
  * perl/python/ruby
establish text processing rules
  * coreutils/busybox/etc
non is perfect, having replacement mechanism allows faster debug
and enhancement of their own development and testing

* UI
  (maybe next time)
  
  Only one thing. I don't have time and will to study all that
  ncurses/slang/qt/gtk/AJAX/whatever stuff. I wanted to do basic terminal
  or text/stream editor friendly user interface. As for the former, i
  just upset about software capabilities of the todays terminal
  emulators. I'm fine with exchanging escape sequences, but all that
  inherited TEKTRONIX 4010, APL, HP2645, Microterm ACT-IV, Ann Arbor
  4080, LSI ADM-3a (man terminfo) legacy without even a hint of progress
  last 20 years is just dead.
  
  I likely to end up with shell script generation, that will be
  available for everybody who knows shell and have ordinary text editor.

  autoconf/configure inside out? Maybe, but at least from the new sheet of
  paper, with good background in history and basic text processing tools.

Just in case anybody cares about how ugly modern software development is
(INA software industry dude, and may be just crazy, of course). Well,
recent Rusty's gig may give a clue, how things may look different.

> For Kbuild I fail to see anything that demand a rewrite from a structure
> view of the Kbuild files.
> The Kbuild internal stuff is antoehr story - here a rewrite to a saner
> language then GNU make syntax could improve hackability a lot.

-
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/3] build system: section garbage collection for vmlinux

[Oleg Verych]

* Wed, 5 Sep 2007 14:43:21 +0100
* User-Agent: KMail/1.9.1
>
> Build system: section garbage collection for vmlinux
>

Maybe this is just a test suit to get finish with `make XYZ static`?

-
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/3] build system: section garbage collection for vmlinux

[Oleg Verych]

On Wed, Sep 05, 2007 at 07:46:11PM +0100, Denys Vlasenko wrote:
> On Wednesday 05 September 2007 16:53, Oleg Verych wrote:
> > * Wed, 5 Sep 2007 14:43:21 +0100
> > * User-Agent: KMail/1.9.1
> > >
> > > Build system: section garbage collection for vmlinux
> > 
> > Maybe this is just a test suit to get finish with `make XYZ static`?
> 
> They are vaguely connected in a sense that unused function which is
> not marked static doesn't generate gcc warning, but will be discarded
> by --gc-sections. "make XYZ static" also tends to find them - you make
> function static, you recompile the file, and gcc informs you that
> the function is not used at all!
> 
> This happened to me when I did aic7xxx patches.
> 
> You may yse --print-gc-sections to see the list of discarded sections.

Anyway, this is gccism/binutilizm. That about other possible/future
options?

Give me example, please, why function must be non static if not used.
If usage requires kconfig tuning, then this is a better way to go, than
to adopt yet another GNU/Luxury.

-
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/

Fast path efficiency (Re: [rfc][patch] dynamic data structure switching)

[Oleg Verych]

* Sun, 2 Sep 2007 20:36:19 +0200
>

I see, that in many places all pre-checks are done in negative form
with resulting return or jump out. In this case, if function was called,
what likely() path is?

> +static void resize_pid_hash(void)
> +{
> + unsigned int old_shift, new_shift;
> +
> + if (system_state != SYSTEM_RUNNING)
> + return;
> +
> + old_shift = cur_pid_hash->shift;
> + new_shift = ilog2(nr_pids * 2 - 1);
> + if (new_shift == old_shift)
> + return;
> +
> + if (!mutex_trylock(&dyn_pidhash.resize_mutex))
> + return;

that one or this?

==
if (system_state == SYSTEM_RUNNING) {
old_shift = cur_pid_hash->shift;
new_shift = ilog2(nr_pids * 2 - 1);
if (new_shift != old_shift && 
mutex_trylock(&dyn_pidhash.resize_mutex)) {
==
> + old_shift = cur_pid_hash->shift;
> + new_shift = ilog2(nr_pids * 2 - 1);

/* hope this repetition is needed by design */

...

> + mutex_unlock(&dyn_pidhash.resize_mutex);
}

What is more efficient in general sense,
as opposed to s,3,2,1,0 Optimized?

> + if (new_shift != old_shift) {
> + struct pid_hash *ph, *ret;
> + unsigned int idx = ph_cur_idx ^ 1;
> + ph = &pid_hashes[idx];
> + if (!init_pid_hash(ph, new_shift)) {
> + ph_cur_idx = idx;
> +
> + ret = dyn_data_replace(&dyn_pidhash, dd_transfer_pids, 
> ph);
> + BUG_ON(ret == ph);
> + BUG_ON(ret != &pid_hashes[idx ^ 1]);
> + /* XXX: kfree(ret->table) */
> + ret->shift = -1;
> + ret->table = NULL;
> + }
> + }
> + mutex_unlock(&dyn_pidhash.resize_mutex);
> +}
> +

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: [PATCH 0/3] build system: section garbage collection for vmlinux

[Oleg Verych]

On Thu, Sep 06, 2007 at 11:55:46AM +0100, Denys Vlasenko wrote:
[]
> > Give me example, please, why function must be non static if not used.
> 
> Where do you see I'm saying that they must be non-static?
> I'm all for marking functions static. I just did it for aic7xxx.
> 
> > If usage requires kconfig tuning, then this is a better way to go,
> 
> We already do it, but we don't have enough developers to audit
> every driver for every possible combination of config options.
> As a result, there always be some amount of unused functions and data.
> Using --gc-sections will discard that.

You've did a tool. Documenting this tool to have it available for
testers/janitors/maintainers is a better way, than to have all that
opinions/problems with merging-to-mainline.

> > than to adopt yet another GNU/Luxury.
> 
> Actually, this is how linkers should have worked long ago.
> Borland's Turbo Pascal was doing it ten+ years ago.
> 
> I don't understand why you are opposed to toolchain helping
> humans to get optimized result. But it's fine with me.
> I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS.

That's why. It's treating symptoms, isn't it?

-
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/3] build system: section garbage collection for vmlinux

[Oleg Verych]

On Thu, Sep 06, 2007 at 02:21:43PM +0200, Adrian Bunk wrote:
[]
> > You've did a tool. Documenting this tool to have it available for
> > testers/janitors/maintainers is a better way, than to have all that
> > opinions/problems with merging-to-mainline.
> 
> There is no problem with his patch.
> 
> His patch improves the build process.

I would like to know timing, btw. Size, especially shown 1%, doesn't
matter if link time increased dramatically. `Allyes' config, when i
had fast and rammish machine was terrible thing (last winter). If 32
cores/cpus is will of author, then i'm even more suspicious.

> And there's no reason to hide this from the users.

Patch? Did i said patch?

Ah, patch. Yes -- hide it, because it against LKML's rules. I can
provide ftp for such things, easily.

I said tool _and_ documentation. Because if developers don't know
about `static' code or _data_ and cann't find out that, then small
description is more than welcome, i think.

But, tool. Hide it also, becasue it's kind of thing to be shamed
of (:

== untested, for demonstation only ==

SED_REM='
/\.text\./s|\.text\.|.text_|g;
/\.data\./s|\.data\.|.data_|g;
/\.bss\.p/s|\.bss\.p|.bss_p|g; # for .bss.page_aligned only
'
for place in linux/arch/* linux/kernel linux/include/asm-*
do case $place
*cris)  ADDON='/\.text\.__/n;'  ;;
*powerpc)   ADDON='/\.data\.rel/n;' ;;
*parisc)ADDON='/\.data\.vm[p0]/n;' ;;
*frv)   ADDON='/\.bss\.stack/n;';;
esac

sed -i -e "$ADDON$SED_REM" `find $place -type f`

done
done

== ==

[]
> > > I don't understand why you are opposed to toolchain helping
> > > humans to get optimized result. But it's fine with me.
> > > I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS.
> > 
> > That's why. It's treating symptoms, isn't it?
> 
> There's nothing that requires treatment.

[Help for] The developers/contributors of those drivers, no?

> It's a matter of fact that the kernel takes advantages from some 
> features of GNU binutils and GNU gcc that might not be available
> in other versions of these tools.
> 
> Whether you like it or not - that's not going to change.

I don't like fast, one-sided solutions.

> But don't continue arguing about something where you won't win with 
> words - it's open source, so you can always create a fork of the Linux 
> kernel that builds with whatever toolchain you want.

I just want to have review process to be real not only in C hacking.

> The only way you could convince other people from your point of view 
> would be if your forked version of the kernel would contain advantages 
> that convince many users to use your kernel rather than Linus' one.
> 
> cu
> Adrian
> 
> -- 

-
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/3] build system: section garbage collection for vmlinux

[Oleg Verych]

* Thu, 6 Sep 2007 22:39:31 +0200

[]
>> > His patch improves the build process.
>> 
>> I would like to know timing, btw. Size, especially shown 1%, doesn't
>> matter if link time increased dramatically. `Allyes' config, when i
>> had fast and rammish machine was terrible thing (last winter). If 32
>> cores/cpus is will of author, then i'm even more suspicious.
>
> For non-developers size and speed of the kernel matter much more than 
> compile time.

I'm talking about benefits for the process (developers, testers) and
the result (end users, dogs eating own food :).

> When you go towards embedded systems with limited resources a 1% size 
> decrease would often be worth it even if it would (hypothetically) 
> increase the compile time by a factor of 10.

   textdata bss dec hex filename
   5159478 1005139  406784 6571401  644589 linux-2.6.23-rc4.org/vmlinux
   5131822  996090  401439 6529351  63a147 linux-2.6.23-rc4.gc/vmlinux

Are this numbers show embedded target? I think no. Also time factor of
*10* can be spent more productively reviewing actual code of parts, that
are going to be embedded, no?

[]
>> > There's nothing that requires treatment.
>> 
>> [Help for] The developers/contributors of those drivers, no?
>>...
>
> They did everything right.
>
> You should better try to understand the problem first before behaving as 
> if you knew everything better than everyone else...

OK, thank you very much. Now, describe what problem you are talking
about, please. I see non.

-
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/3] build system: section garbage collection for vmlinux

[Oleg Verych]

* Thu, 6 Sep 2007 23:19:55 +0200
>
> On Thu, Sep 06, 2007 at 11:16:15PM +0200, Oleg Verych wrote:
>> * Thu, 6 Sep 2007 22:39:31 +0200
>> 
>> []
>> >> > His patch improves the build process.
>> >> 
>> >> I would like to know timing, btw. Size, especially shown 1%, doesn't
>> >> matter if link time increased dramatically. `Allyes' config, when i
*if*
>> >> had fast and rammish machine was terrible thing (last winter). If 32
>> >> cores/cpus is will of author, then i'm even more suspicious.
>> >
>> > For non-developers size and speed of the kernel matter much more than 
>> > compile time.
>> 
>> I'm talking about benefits for the process (developers, testers) and
>> the result (end users, dogs eating own food :).
>
> Your claim was that link time was more important than code size, and 
> that claim is in many cases wrong.

I just noted, that maybe (*if*) build/link time have been affected.
There was an example of size reduction, why not to have timings also?

I guess, developer can spend time tuning written driver with that
option/patch. But what you will write in the help message for
testers/users? In this case build time is important obviously. Runtime
isn't affected at all, except, maybe, ~1% increase in bzImage unzipping.

Whatever.

>> > When you go towards embedded systems with limited resources a 1% size 
>> > decrease would often be worth it even if it would (hypothetically) 
>> > increase the compile time by a factor of 10.
>> 
>>textdata bss dec hex filename
>>5159478 1005139  406784 6571401  644589 linux-2.6.23-rc4.org/vmlinux
>>5131822  996090  401439 6529351  63a147 linux-2.6.23-rc4.gc/vmlinux
>> 
>> Are this numbers show embedded target? I think no. Also time factor of
>> *10* can be spent more productively reviewing actual code of parts, that
>> are going to be embedded, no?
>
> First of all, please lookup the word "hypothetically" in a dictionary.

Do you mean hand-waving?

Whatever.

> And code review and Denys' patch have cumulative effects since his patch 
> results in improvements that can't be resonably done other than at 
> the ld and/or gcc level.

I was talking about introducing such things in development process.
Current kconfig may be not flexible, it must not lead to further problems
and silver-bullet solutions.

>> []
>> >> > There's nothing that requires treatment.
>> >> 
>> >> [Help for] The developers/contributors of those drivers, no?
>> >>...
>> >
>> > They did everything right.
>> >
>> > You should better try to understand the problem first before behaving as 
>> > if you knew everything better than everyone else...
>> 
>> OK, thank you very much. Now, describe what problem you are talking
>> about, please. I see non.
>
> If you don't understand what the patches in this thread are about then 
> you shouldn't have started commenting on this thread...

Not first time i see, what i should do. Thank you very much, Adrian!
You know better, what i know. Great.

Then say from the beginning that you're not interested in reviewing
and view-exchanging process, you know better, what i should do. Thus, i
will not waste my time explaining anything.

Whatever.

-
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] ELAN U132 Host Controller Driver: convert sw_lock to mutex

[Oleg Verych]

* Thu, 6 Sep 2007 23:18:15 +0200

[]
> @@ -184,7 +184,7 @@ struct u132_ring {
>  struct u132 {

Subject: [PATCH 1/2] ELAN U132 Host Controller Driver: convert sw_lock to mutex
[]
>  struct list_head u132_list;
> -struct semaphore sw_lock;
> +struct mutex sw_lock;
>  struct semaphore scheduler_lock;

Subject: [PATCH 2/2] ELAN U132 Host Controller Driver: convert  scheduler_lock t
[]
> struct list_head u132_list;
> struct semaphore sw_lock;
>-struct semaphore scheduler_lock;
>+struct mutex scheduler_lock;

Are you sure, you have right patch sequence?

-
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 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: 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/

dfsg isn't fsf (Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19])

[Oleg Verych]

On 2006-12-14, Alan wrote:
[]
> I doubt any distribution but the FSF "purified" Debian (the one that has
> no firmware so doesn't work) would do it.

DFSG "purified" Debian[1], please.

[1] 

--
-o--=O C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found  o ( yes! -- R.I.P. FSF+RMS, viva )
<___=E M  man gcc: not found`-- ( Debian Free Operating System )

-
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/

[ot] Re: coding style and re-inventing the wheel way too many times

[Oleg Verych]

On 2006-12-21, Robert P. J. Day wrote:
[]
>   in any event, even *i* am not going to go near this kind of cleanup,
> but is there anything actually worth doing about it?  just curious.

Moscow wasn't built at once...

You may notice as some others are doing little by little steps:
- source cleanups;
- right dependancy;
- headers includes;
- warnings elimination;
- code reading-analyzing (brainwashing, as for me;) and a few line
fixes everywhere.

I think there are members here, who doing things, like that for at
least two years.

You are trying to focus (mostly) on style and sense -- ok. And maybe it's
like to be alone within a crowd. Anyways, as long as you fill, that you
can do that, and patches are accepded, changes are *documented* its ok,
also. Sometimes it's stupid, worthless or something else. If so, then
find more interesting things to do, unless you are going to proof
something to somebody ;E.

Here's, as i can see, almost no place for emotions, only technical stuff
and everything not far from it. See, there isn't any reply on you
message, except this one. I think, because of that.

--
-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: [updated PATCH] remove 555 unneeded #includes of sched.h

[Oleg Verych]

On 2006-12-29, Tim Schmielau wrote:
[]
> OK, building 2.6.20-rc2-mm1 with all 59 configs from arch/arm/configs 
> with and w/o the patch indeed found one mysterious #include that may not 
> be removed. Thanks, Russell!
>
> Andrew, please use the attached patch instead of the previous one, it also 
> has a slightly better patch description.

Great job!

About patch. To make it smaller, i think, you better use less
"unified context" lines `diff -u1'.

Nice done! 


-
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: Replace remaining "depends" with "depends on"

[Oleg Verych]

On 2006-12-13, Robert P. J. Day wrote:
>
>   Replace the very few remaining "depends" Kconfig directives with
> "depends on".
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---

For this kind of fixes, please use
"kconfig" subsystem instead of
"kbuild" in subject. 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/

[fix, rfc] kbuild: O= with M= (Re: [PATCH -mm] replacement for broken kbuild-dont-put-temp-files-in-the-source-tree.patch)

[Oleg Verych]

On 2006-11-17, Oleg Verych wrote:
> On Tue, Oct 31, 2006 at 02:51:36PM +0100, olecom wrote:
> []
>> On Tue, Oct 31, 2006 at 02:14:16AM +0100, Horst Schirmeier wrote:
> []
>> > I'm not sure what you mean by $(objdir); I just got something to work
>> > which creates the /dev/null symlink in a (newly created if necessary)
>> > directory named
>> 
>> $(objtree) is a directory for all possible outputs of the build precess,
>> it's set up by `O=' or `KBUILD_OUTPUT', and this is *not* output for ready
>> external modules `$(M)'. Try to play with this, please.
>
> And for me, they are *not* working together:

It works with this:

Proposed-by: me

--- linux-2.6.20-rc5/scripts/Makefile.modpost.orig  2007-01-12 
19:54:26.0 +0100
+++ linux-2.6.20-rc5/scripts/Makefile.modpost   2007-01-23 08:23:51.583426500 
+0100
@@ -58,5 +58,5 @@
 #  Includes step 3,4
 quiet_cmd_modpost = MODPOST $(words $(filter-out vmlinux FORCE, $^)) modules
-  cmd_modpost = scripts/mod/modpost\
+  cmd_modpost = $(objtree)/scripts/mod/modpost \
 $(if $(CONFIG_MODVERSIONS),-m) \
$(if $(CONFIG_MODULE_SRCVERSION_ALL),-a,)  \
>> 
> 


-
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/

+1 4 cz (Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit)

[Oleg Verych]

In gmane.linux.kernel, David Miller wrote:
> From: Alan Cox <[EMAIL PROTECTED]>
> Date: Mon, 22 Jan 2007 07:45:02 -0500
>
>> On Mon, Jan 22, 2007 at 12:07:11PM +0100, Christoph Hellwig wrote:
>> > > process.  This year, the Kernel Summit will be held in Cambridge,
>> > > England, at the DeVere University Arms Hotel, September 5-6 (with a
>> > > welcome reception on the 4th).  The decision to move the Kernel Summit
>> > > to England is a one-year experiment based on the very strong request of
>> > > last year's kernel summit attendees to try a location outside of Ottawa,
>> > > and especially from the roughly 1/3rd of the attendees that come from
>> > > the UK or Europe.  So the plan is for us to book the Ottawa Congress
>> > > Ceter space for July 2008 (which we will need to do by mid-year 2007),
>> 
>> Ditto..
>> 
>> Definitely disagree with that. I'd like to see the conference somewhere
   else different this time - perhaps *Czech Republic*, or somewhere else more
>> easterly and Linux active (or even Finland...)
>
> This is my position as well.
[]
> For the first time in many years I'm strongly considering actually
> going to the kernel summit, however if it goes back to Ottawa I
> definitely will stop going again.

It would be interesting. Thank you Alan, David!

;D

-
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: identifying CONFIG variable typoes in the source tree

[Oleg Verych]

On 2007-01-23, Robert P. J. Day wrote:
[]
>   what it does is scan the entire tree for lines of the form
>
> ...if... CONFIG_whatever...
>
> collects all of those CONFIG variables and, one at a time, checks to
> see if that variable even exists in any Kconfig file in the tree so
> that it could possibly ever be set.  (i'm not guaranteeing that the
> script is perfect, but it does generate some interesting results.)
>
>   the first few lines of output:
>
> 53C700_BE_BUS
> 64_BIT
> 68328_SERIAL_UART2
> ...
>
[]
>   the script turns up 284 examples of this.

Next, this script must to learn how to search whom to send this info.
And if there's nobody, just to make list of known orphans ;).

> rday



-
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: [KBUILD] I don't want initramfs in 2.6.19.1 but usr/ is still processed

[Oleg Verych]

On 2007-01-03, DervishD wrote:
>
> Hi all :)

Hallo!

> I've noticed that, even if I say NO to initramfs (and even ramdisk
> support), the make process wants to GEN usr/initramfs_data.cpio.gz by
> running the scripts/gen_initramfs_list.sh script.
>
> Why is that script run no matter the initramfs support? Looks like
> it only depends on the contents of CONFIG_INITRAMFS_SOURCE :?

I think reading Documentation/filesystems/ramfs-rootfs-initramfs.txt
will answer your question.

> Thanks in advance :)
>
> RaЗl NЗЯez de Arenas Coronado
>
> -- 
> Linux Registered User 88736 | http://www.dervishd.net
> It's my PC and I'll cry if I want to... RAmen!


-
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] kbuild: create KBUILD_OUTPUT

[Oleg Verych]

kbuild: create KBUILD_OUTPUT

 When requesting build to another directory, try to create it first.

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

,-*- bash -*-
|[EMAIL PROTECTED]:~/kernel.org/_work/src/linux-2.6.20-rc5$
|[EMAIL PROTECTED]:~/kernel.org/_work/src/linux-2.6.20-rc5$ make O=/tmp/build
|cd: 1: can't cd to /tmp/build
|Makefile:116: *** output directory "/tmp/build" does not exist.  Stop.
|[EMAIL PROTECTED]:~/kernel.org/_work/src/linux-2.6.20-rc5$ patch -p1 
<../../va-patch/
|kbuild-create-output-dir.patch
|patching file Makefile
|[EMAIL PROTECTED]:~/kernel.org/_work/src/linux-2.6.20-rc5$ make O=/tmp/build
|HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc make[3]: ***
|[scripts/basic/docproc] Interrupt make[2]: *** [scripts_basic] Interrupt
|make: *** [_all] Interrupt
|
|[EMAIL PROTECTED]:~/kernel.org/_work/src/linux-2.6.20-rc5$
`-*-

--- linux-2.6.20-rc5/Makefile~orig  2007-01-12 19:54:26.0 +0100
+++ linux-2.6.20-rc5/Makefile   2007-01-24 00:59:55.926951750 +0100
@@ -113,5 +113,5 @@
 # check that the output directory actually exists
 saved-output := $(KBUILD_OUTPUT)
-KBUILD_OUTPUT := $(shell cd $(KBUILD_OUTPUT) && /bin/pwd)
+KBUILD_OUTPUT := $(shell d=$(KBUILD_OUTPUT) ; mkdir -p $$d && cd $$d && pwd)
 $(if $(KBUILD_OUTPUT),, \
  $(error output directory "$(saved-output)" does not exist))
-
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/

[newbie] Re: Is it possible to directly call do_path_lookup() in kernel?

[Oleg Verych]

On 2007-01-24, Xin Zhao wrote:
> Archived-At: 

Hallo.

> I just successfully called do_path_lookup() in my kernel module. I
> just removed the "fastcall" from the declaration of do_path_lookup(),
> then the problem disappeared. I don't quite understand "fastcall"
> though.

In linkage.h header near you.

> Can someone explain it?

Please use appropriate mailing list:

Kernelnewbies: Help each other learn about the Linux kernel.
Archive:   http://mail.nl.linux.org/kernelnewbies/
FAQ:   http://kernelnewbies.org/faq/

> Thanks,
> -x
>


-
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] kbuild: improving option checking (Re: [PATCH -mm] replacement for broken kbuild-dont-put-temp-files-in-the-source-tree.patch)

[Oleg Verych]

Hallo. Tmpfiles, root users, external mod-builds again.

On Tue, Oct 31, 2006 at 02:51:36PM +0100, olecom wrote:
> On Tue, Oct 31, 2006 at 02:14:16AM +0100, Horst Schirmeier wrote:
> > On Tue, 31 Oct 2006, Andi Kleen wrote:
> > > 
> > > > The problem is, this brings us back to the problem where this whole
> > > > patch orgy began: Gentoo Portage sandbox violations when writing (the
> > > > null symlink) to the kernel tree when building external modules. What
> > > > about using $(M) as a base directory if it is defined?
> > > 
> > > I think Jan's $(objdir)/.tmp proposal would be cleanest. Just someone
> > > has to implement it :)
> > > 
> > > -Andi
> 
> $(objtree) here,
> 
> > I'm not sure what you mean by $(objdir); I just got something to work
> > which creates the /dev/null symlink in a (newly created if necessary)
> > directory named
> 
> $(objtree) is a directory for all possible outputs of the build precess,
> it's set up by `O=' or `KBUILD_OUTPUT', and this is *not* output for ready
> external modules `$(M)'. Try to play with this, please.

Kind of fix has finally landed. Instead for `O=/$dir' a patch...

Anyway i whould like propose my solution of:
-- external modules build without KBUILD_OUTPUT set;
-- /dev/null, GNU binutils and root users;
-- beauty;

For external modules, there must be information after
`make modules_prepare' in shipped linux-sources. Any build output is
put in $(objtree), and i don't understand why you don't using that.
Please, *try* `make O=/tmp/build M=/usr/local/src/nvatia'. Thank you.

As some kind of buga-feature, "null" isn't in any clean/mrproper
target (for a while ;).

-*- patch -*-
kbuild: improving option checking

 GNU binutils, root users, tmpfiles, external modules ro builds must
 be fixed to do the right thing now.

 In "safe" environment new /dev/null replacement may be used as simply as
 `echo > null', `gcc -o null'. In aggressive starting with $(null) is
 recommended.

 Feature: file $(objtree)/null isn't in any "clear" target (yet).

Cc: Roman Zippel <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
Signed-off-by: Oleg Verych <[EMAIL PROTECTED]>
---
-o--=O`C
 #oo'L O
<___=E M

--- linux~2.6.20-rc5/scripts/Kbuild.include~blackhole-4-tmpfiles
2007-01-12 19:54:26.0 +0100
+++ linux~2.6.20-rc5/scripts/Kbuild.include 2007-01-24 09:19:01.386426000 
+0100
@@ -2,5 +2,5 @@
 # kbuild: Generic definitions
 
-# Convinient variables
+# Convinient constants
 comma   := ,
 squote  := '
@@ -8,4 +8,7 @@
 space   := $(empty) $(empty)
 
+# Immortal black-hole for mortals and roots
+null = $(shell test -L null || (rm -f null; ln -s /dev/null null); echo null)
+
 ###
 # Name of target with a '.' as filename prefix. foo/bar.o => foo/.bar.o
@@ -57,33 +60,43 @@
 # See documentation in Documentation/kbuild/makefiles.txt
 
-# output directory for tests below
-TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/)
-
 # as-option
 # Usage: cflags-y += $(call as-option, -Wa$(comma)-isa=foo,)
-
-as-option = $(shell if $(CC) $(CFLAGS) $(1) -Wa,-Z -c -o /dev/null \
--xassembler /dev/null > /dev/null 2>&1; then echo "$(1)"; \
-else echo "$(2)"; fi ;)
+define as-option
+  $(shell
+if $(CC) $(CFLAGS) $(1) -c -o $(null) -xassembler null >null 2>&1; \
+  then echo $(1); \
+  else echo $(2); \
+fi)
+endef
 
 # as-instr
 # Usage: cflags-y += $(call as-instr, instr, option1, option2)
-
-as-instr = $(shell if echo -e "$(1)" | \
- $(CC) $(AFLAGS) -c -xassembler - \
-   -o $(TMPOUT)astest.out > /dev/null 2>&1; \
-  then rm $(TMPOUT)astest.out; echo "$(2)"; \
-  else echo "$(3)"; fi)
+define as-instr
+  $(shell \
+if printf "$(1)" | $(AS) >$(null) 2>&1 -W -o null; \
+  then echo "$(2)"; \
+  else echo "$(3)"; \
+fi)
+endef
 
 # cc-option
 # Usage: cflags-y += $(call cc-option, -march=winchip-c6, -march=i586)
-
-cc-option = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \
- > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)
+define cc-option
+  $(shell \
+if $(CC) $(CFLAGS) $(1) -S -o $(null) -xc null >null 2>&1; \
+  then echo "$(1)"; \
+  else echo "$(2)"; \
+fi)
+endef
 
 # cc-option-yn
 # Usage: flag := $(call cc-option-yn, -march=winchip-c6)
-cc-option-yn = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \
-> /dev/null 2>&1; then echo "y";

[patch] spell 4 kbuild: improving option checking

[Oleg Verych]

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

--- linux~2.6.20-rc5/scripts/Kbuild.include~2007-01-24 09:19:01.386426000 
+0100
+++ linux~2.6.20-rc5/scripts/Kbuild.include 2007-01-24 20:07:11.15282 
+0100
@@ -2,5 +2,5 @@
 # kbuild: Generic definitions
 
-# Convinient constants
+# Convenient constants
 comma   := ,
 squote  := '
@@ -171,5 +171,5 @@
 any-prereq = $(filter-out $(PHONY),$?) $(filter-out $(PHONY) $(wildcard $^),$^)
 
-# Execute command if command has changed or prerequisitei(s) are updated
+# Execute command if command has changed or prerequisite(s) are updated
 #
 if_changed = $(if $(strip $(any-prereq) $(arg-check)),   \
@@ -188,5 +188,5 @@
 
 # Usage: $(call if_changed_rule,foo)
-# will check if $(cmd_foo) changed, or any of the prequisites changed,
+# will check if $(cmd_foo) changed, or any of the prerequisites changed,
 # and if so will execute $(rule_foo)
 if_changed_rule = $(if $(strip $(any-prereq) $(arg-check) ), \
@@ -233,2 +233,4 @@
 echo-why = $(call escsq, $(strip $(why)))
 endif
+
+ LocalWords:  prequisites
-
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/

[rft] (g)awk substitution (Re: [PATCH] sed s/gawk/awk/scripts/gen_init_ramfs.sh)

[Oleg Verych]

> On Tuesday 23 January 2007 7:49 pm, Andrew Morton wrote:
>> If the kernel is being compiled on a non-Linux system (eg: legacy Unix)
>> then it is, I guess, possible for `awk' and `gawk' to offer different
>> features.  If the kernel's use of gawk uses GNU extensions then this patch
>> might break things on such a system.
>> 
>> I guess we'll find out...

OK, this is what (g) awk is needed for:

,-*- diff: shell script -*-
|local maj=$(LC_ALL=C ls -l "${location}" | \
|   -   gawk
|'{sub(/,/, "", $5); print $5}')
|+   awk '{sub(/,/, "", $5); print
|$5}')
|local min=$(LC_ALL=C ls -l "${location}" | \
|   -   gawk
|'{print $6}')
|+   awk '{print $6}')
|
|if [ -b "${location}" ]; then
|   dev_type="b"
|   @@ -134,7
|+134,7 @@
|;;
|   "slink")
|   local
|target=$(LC_ALL=C ls -l "${location}" | \
|-   gawk '{print $11}')
|+   awk '{print $11}')
`-*-

Let me propose you to test this as solution, that need no awk, only shell:
-*- sh -*-
#/bin/sh
# usage: $0 node symlink

nod=$1
sym=$2

pos_param() {
  set -- $@
  shift $1
  echo $1
}

location=${nod}
maj=`pos_param 5 $(LC_ALL=C ls -l "${location}")`
maj=${maj%,}
min=`pos_param 6 $(LC_ALL=C ls -l "${location}")`
echo "maj min:" $maj $min

location=${sym}
target=`pos_param 11 $(LC_ALL=C ls -l "${location}")`
echo "symlink target:" ${target}

-*- Result of testcase -*-
[EMAIL PROTECTED]:/tmp$ ./awkless.sh /dev/null null
maj min: 1 3
symlink target: /dev/null
[EMAIL PROTECTED]:/tmp$
[EMAIL PROTECTED]:/tmp$
-*-

p.s. who is going to make alternative to GNU make ? ;D
---
-o--=O`C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found  o (R.I.P. Debian Operating System)
<___=E M  man gcc: not found.-- (  TNX, RMS.   )
-
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, rft] scripts/gen_initramfs_list.sh: replace gawk with shell, whitespace cleanup

[Oleg Verych]

scripts/gen_initramfs_list.sh: replace gawk with shell, whitespace cleanup

Signed-off-by: Oleg Verych <[EMAIL PROTECTED]>
---
-o--=O`C
 #oo'L O
<___=E M

--- linux~2.6.20-rc5/scripts/gen_initramfs_list.sh~ 2007-01-12 
19:54:26.0 +0100
+++ linux~2.6.20-rc5/scripts/gen_initramfs_list.sh  2007-01-24 
22:54:49.721441250 +0100
@@ -1,5 +1,6 @@
 #!/bin/bash
 # Copyright (C) Martin Schlemmer <[EMAIL PROTECTED]>
-# Copyright (c) 2006   Sam Ravnborg <[EMAIL PROTECTED]>
+# Copyright (C) 2006 Sam Ravnborg <[EMAIL PROTECTED]>
+# Copyright (C) 2007 Oleg Verych <[EMAIL PROTECTED]>
 #
 # Released under the terms of the GNU GPL
@@ -18,13 +19,13 @@
 $0 [-o ] [-u ] [-g ] {-d | } ...
-o   Create gzipped initramfs file named  using
-  gen_init_cpio and gzip
+  gen_init_cpio and gzip
-uUser ID to map to user ID 0 (root).
-   is only meaningful if 
-  is a directory.
+   is only meaningful if 
+  is a directory.
-gGroup ID to map to group ID 0 (root).
-   is only meaningful if 
-  is a directory.
+   is only meaningful if 
+  is a directory.
  File list or directory for cpio archive.
-  If  is a .cpio file it will be used
+  If  is a .cpio file it will be used
   as direct input to initramfs.
-d Output the default cpio list.
@@ -95,4 +96,11 @@
 }
 
+# accessing fields, as in `awk'
+# $1 - field number; rest is argument string
+pos_param() {
+   shift $1
+   echo $1
+}
+
 # for each file print a line in following format
 #  
@@ -120,9 +128,7 @@
;;
"nod")
-   local dev_type=
-   local maj=$(LC_ALL=C ls -l "${location}" | \
-   gawk '{sub(/,/, "", $5); print $5}')
-   local min=$(LC_ALL=C ls -l "${location}" | \
-   gawk '{print $6}')
+   maj=`pos_param 5 $(LC_ALL=C ls -l "${location}")`
+   min=`pos_param 6 $(LC_ALL=C ls -l "${location}")`
+   maj=${maj%,}
 
if [ -b "${location}" ]; then
@@ -134,6 +140,5 @@
;;
"slink")
-   local target=$(LC_ALL=C ls -l "${location}" | \
-   gawk '{print $11}')
+   target=`pos_param 11 $(LC_ALL=C ls -l "${location}")`
str="${ftype} ${name} ${target} ${str}"
;;
-
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, rft] scripts/makelst: replace gawk with shell, update

[Oleg Verych]

scripts/makelst: replace gawk with shell, update

Signed-off-by: Oleg Verych <[EMAIL PROTECTED]>
---
-o--=O`C
 #oo'L O
<___=E M

--- linux~2.6.20-rc5/scripts/makelst~   2007-01-12 19:54:26.0 +0100
+++ linux~2.6.20-rc5/scripts/makelst2007-01-24 23:21:33.273657000 +0100
@@ -1,19 +1,22 @@
-#!/bin/bash
+#!/bin/sh
 # A script to dump mixed source code & assembly
 # with correct relocations from System.map
-# Requires the following lines in Rules.make.
-# Author(s): DJ Barrow ([EMAIL PROTECTED],[EMAIL PROTECTED]) 
-#William Stearns <[EMAIL PROTECTED]>
+# Requires the following lines in makefile:
 #%.lst: %.c
 #  $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$@) -g -c -o $*.o $<
-#  $(TOPDIR)/scripts/makelst $*.o $(TOPDIR)/System.map $(OBJDUMP)
+#  $(srctree)/scripts/makelst $*.o $(srctree)/System.map $(OBJDUMP)
 #
-#Copyright (C) 2000 IBM Corporation
-#Author(s): DJ Barrow ([EMAIL PROTECTED],[EMAIL PROTECTED]) 
+# Copyright (C) 2000 IBM Corporation
+# Author(s): DJ Barrow ([EMAIL PROTECTED],[EMAIL PROTECTED])
+#William Stearns <[EMAIL PROTECTED]>
 #
 
+pos_param() {
+  shift $1 ; echo $1
+}
+
 t1=`$3 --syms $1 | grep .text | grep " F " | head -n 1`
 if [ -n "$t1" ]; then
-  t2=`echo $t1 | gawk '{ print $6 }'`
+  t2=`pos_param 6 $t1`
   if [ ! -r $2 ]; then
 echo "No System.map" >&2
@@ -21,6 +24,6 @@
   else
 t3=`grep $t2 $2`
-t4=`echo $t3 | gawk '{ print $1 }'`
-t5=`echo $t1 | gawk '{ print $1 }'`
+t4=`pos_param 1 $t3`
+t5=`pos_param 1 $t1`
 t6=`echo $t4 - $t5 | tr a-f A-F`
 t7=`( echo  ibase=16 ; echo $t6 ) | bc`

-
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/

sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)

[Oleg Verych]

On Wed, Jan 24, 2007 at 08:51:32PM -0500, Rob Landley wrote:
> On Wednesday 24 January 2007 4:03 pm, Oleg Verych wrote:
> 
> > Let me propose you to test this as solution, that need no awk, only shell:
> 
> Actually awk is one of the standard Single Unix Specification (version 3) 
> utilities and the kernel build uses it in a number of places, such as 
> arch/alpha/boot/Makefile, drivers/eisa/Makefile, scripts/ver_linux.

I saw that. If you will test my first replacements and it will be ok,
i will go to this.

> Your objection is a bit like saying "and don't use cat".  I'm saying don't 
> call cat "gcat" when you just mean plain old cat.

No it's not, really. I don't want to see pipes, fork()s, disk seek,
when task can be done without it. I know, what awk is, and i hope it
will have its better time.

> > p.s. who is going to make alternative to GNU make ? ;D
> 
> Me.  Seriously.  It's on my todo list, as part of the Firmware Linux project:

Well. I didn't expect such answer! So, after my trying to deal with
makefiles (there so many to cleanup and structure), i think it will be
easy to do so. I did contacted (ft)jam developers, but didn't get any
answer on current state of it vs GNU make.

> http://lwn.net/Articles/215941/
> 
> Although as major projects go, it's about fifth down on the list after 
> getting 
> toybox up to speed, writing a proper bash replacement shell, getting tcc to 
> build an unmodified Linux kernel, convincing the uClibc guys to HAVE ANOTHER 
> RELEASE ALREADY (it's been a year and a half, I _sent_ a cake)...

Thanks for information.

> Today, I'm writing a gene2fs that produces streaming output (I.E. it works 
> like tar).  It's not done yet...

Good luck !


-
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: Intel PCI-E bridge ACPI resources and possibly related SATA unstability problems on ASUS A8Js

[Oleg Verych]

gmane.linux.kernel:
> Hi,

Hallo.

> recently I got my hands on an ASUS A8Js notebook (Core 2 Duo T7200,
> Intel 945 PM PCI-E Chipset, for details see attached log). After booting 
> the latest 2.6.20-rc5-git3 kernel (but the same behaviour occurs also with 
> the 2.6.19.2, didn't try any other), some strange behaviour can be 
> observed.

There were disscussions about mmconfig and what nightmare it brought to
PCI(E) configuration in scope of BIOS, chip bugs. Here's (one of) such:


> At first the following messages appear in the log:
>
> ...
> [   40.303154] PCI: BIOS Bug: MCFG area at e000 is not E820-reserved
> [   40.303157] PCI: Not using MMCONFIG.
>
> (not sure whether this is really a problem)

I think it may be the major problem.


-
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: Intel PCI-E bridge ACPI resources and possibly related SATA unstability problems on ASUS A8Js

[Oleg Verych]

On Thu, Jan 25, 2007 at 01:28:56PM +0100, Martin Drab wrote:
> On Thu, 25 Jan 2007, Oleg Verych wrote:
> 
> > gmane.linux.kernel:
> > > recently I got my hands on an ASUS A8Js notebook (Core 2 Duo T7200,
> > > Intel 945 PM PCI-E Chipset, for details see attached log). After booting 
> > > the latest 2.6.20-rc5-git3 kernel (but the same behaviour occurs also 
> > > with 
> > > the 2.6.19.2, didn't try any other), some strange behaviour can be 
> > > observed.
> > 
> > There were disscussions about mmconfig and what nightmare it brought to
> > PCI(E) configuration in scope of BIOS, chip bugs. Here's (one of) such:
> > <http://marc.theaimsgroup.com/?l=linux-kernel&m=116007091004503&w=2>
> > 
> > > At first the following messages appear in the log:
> > >
> > > ...
  [   40.303154] PCI: BIOS *Bug*: MCFG area at e000 is not E820-reserved
> > > [   40.303157] PCI: Not using MMCONFIG.
> > >
> > > (not sure whether this is really a problem)
> > 
> > I think it may be the major problem.
> 
> Hmm, it may be. Was there suggested any solution (or at least proposal) 
> that I may try?

Try fix BIOS bugs: <http://permalink.gmane.org/gmane.linux.kernel/462632>

> Martin

-
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: sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)

[Oleg Verych]

On Thu, Jan 25, 2007 at 01:03:32PM -0500, Rob Landley wrote:
> On Thursday 25 January 2007 4:40 am, Oleg Verych wrote:
> > > Your objection is a bit like saying "and don't use cat".  I'm saying 
> > > don't 
> > > call cat "gcat" when you just mean plain old cat.
> > 
> > No it's not, really. I don't want to see pipes, fork()s, disk seek,
> > when task can be done without it. I know, what awk is, and i hope it
> > will have its better time.
> 
> *shrug*  Making the need for "gawk" go away was my goal, and gawk->awk was 
> the 
> minimal change.  If you want more than that, I'm not objecting, just not 
> personally interested.

Yes making uclibc as a bit more work, than rename things ;D. And my
change is mainly from optimization point of view (say modern embedded ;)

> I believe "shift 5" is also SUSv3. :)

If you have tested, please send ack or nack to us.

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: sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)

[Oleg Verych]

On Thu, Jan 25, 2007 at 02:38:02PM -0500, Rob Landley wrote:
> On Thursday 25 January 2007 2:14 pm, Oleg Verych wrote:
> > > I believe "shift 5" is also SUSv3. :)
> > 
> > If you have tested, please send ack or nack to us.
> 
> I have not.  I tested the one I sent.  Today I'm at a different location than 
> that test environment.  All I can try it on here is Ubuntu, and so could you 
> just as easily.
> 
> As I said, I'm not particularly interested in a more intrusive solution 
> solving a problem I haven't actually seen.  I don't see any obvious reason 
> why it wouldn't work, and yes it would probably also solve my problem, but I 
> still don't see why you think it's "better" than the three byte fix.

Ehhh. "I'm not guilty" issue. Well, fine ;)

If your current system is IA-32, or you have access to one, would you
like to test scripts/makelst for me, as i'm seeing `bc' there. But my
system have not one, i would like to replace it with shell or awk or
whatever. TIA.


-
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 006 of 6] md: Add support for reshape of a raid6

[Oleg Verych]

> From: Andrew Morton
> Newsgroups: gmane.linux.raid,gmane.linux.kernel
> Subject: Re: [PATCH 006 of 6] md: Add support for reshape of a raid6
> Date: Wed, 21 Feb 2007 14:48:06 -0800

Hallo.

> On Tue, 20 Feb 2007 17:35:16 +1100
> NeilBrown <[EMAIL PROTECTED]> wrote:
>
>> +for (i = conf->raid_disks ; i-- ;  ) {
>
> That statement should be dragged out, shot, stomped on then ceremonially
> incinerated.
>
> What's wrong with doing
>
>   for (i = 0; i < conf->raid_disks; i++) {
>
> in a manner which can be understood without alcoholic fortification?
>
> ho hum.

In case someone likes to do job, GCC usually ought to do, i would
suggest something like this instead:

   if (expanded && test_bit(STRIPE_EXPANDING, &sh->state)) {
   /* Need to write out all blocks after computing P&Q */
-   sh->disks = conf->raid_disks;
+   i = conf->raid_disks;
+   sh->disks = i;
-   sh->pd_idx = stripe_to_pdidx(sh->sector, conf,
-conf->raid_disks);
+   sh->pd_idx = stripe_to_pdidx(sh->sector, conf, i);

   compute_parity6(sh, RECONSTRUCT_WRITE);
-   for (i = conf->raid_disks ; i-- ;  ) {
+   do {
   set_bit(R5_LOCKED, &sh->dev[i].flags);
   locked++;
   set_bit(R5_Wantwrite, &sh->dev[i].flags);
-   }
+   } while (--i);

   clear_bit(STRIPE_EXPANDING, &sh->state);
   } else if (expanded) {

In any case this is subject of scripts/bloat-o-meter.

-
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/

loops (Re: [PATCH 006 of 6] md: Add support for reshape of a raid6)

[Oleg Verych]

> From: Neil Brown
> Newsgroups: gmane.linux.raid,gmane.linux.kernel
> Subject: Re: [PATCH 006 of 6] md: Add support for reshape of a raid6
> Date: Thu, 22 Feb 2007 13:39:56 +1100
[]
> I guess...  "Egoless programmer" and all that, "write for others to
> read, not for the compiler",

Few years back on AVR GCC uC architecture, suggested by me
do {...} while(--i) resulted to different numbers of loops with
different optimization levels...

Compilers are written by humans anyway.

-
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/

x86 hardware and transputers (Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3)

[Oleg Verych]

> From: "Michael K. Edwards"
> Newsgroups: gmane.linux.kernel
> Subject: Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
> Date: Thu, 22 Feb 2007 00:59:10 -0800

[striping cc list]

[]
> On 2/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>> > [...] As for threadlets, making them kernel threads is not such a good
>> > design feature, O(1) scheduler or not.  You take the full hit of
>> > kernel task creation, on the spot, for every threadlet that blocks.
>> > [...]
>>
>> this is very much not how they work. Threadlets share the same basic
>> infrastructure with syslets and they do /not/ take a 'full hit of kernel
>> thread creation' when they block. Please read the announcements, past
>> discussions on lkml and the code about how it works.
[]
> Yes, I will go back and read the code for myself.  This will take me
> some time because I have only a hand-waving level of knowledge about
> task_structs and pt_regs, and have largely avoided the dark corners of
> the x86 architecture.

This architecture was brought to us by windows on our screens. And it
took years (a decade?) for them to use all hardware features:

  (IA-32, i386) --> (MS Windows NT,9X)

Yet you must still do much system programming to use that features.

While

> But I think my point still stands: allowing code inside threadlets to
> use the usual C library wrappers around the usual synchronous syscalls
> is going to mean that the threadlet context is fairly heavyweight, both
> in memory and CPU/MMU state.  This means that you can't pull it cheaply
> over to whatever CPU core happened to process the device I/O that
> delivered the data it wanted.
[]
> Oh, and while I haven't written a kernel or an RDBMS, I have written
> some fairly serious non-blocking I/O code (without resorting to
> threads; one socket and thousands of independent userspace state
> machines) and rewritten the plumbing of two fairly heavy-duty network
> operations frameworks, one of them attached to a horrifically complex
> GUI.  And briefly, long ago, I made Transputers dance with Occam and
> galaxies spin with PVM.

transputers were (AFAIK) completely orthogonal to any today's x86 CPU
architecture -- hardware parallelism, special programming language and
technique to match this hardware. And they were chosen to work on Mars in
mid-90th, while crowd wanted more stupid windows on cheap CPUs.

> This gives me exactly zero credentials here, of course, but may suggest
> to you that when I say something that seems naive, it's more likely
> that I got the Linux-specific lingo wrong. That, or I'm _actively_
> stupid.  :-)

Thus, i think, you are thinking mostly on hardware level, while it's
longstanding software problem, i.e. to use x86 (:.

Regards.
--
-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/

.mailmap in top directory

[Oleg Verych]

On Wed, Feb 07, 2007 at 10:42:27PM -0800, Andrew Morton wrote:
[]
> > > add-mailmap-for-proper-git-shortlog-output.patch
> > 
> > i can't tell anything about this one. For what?
> 
> Beats me.  git stuff.  I'll let Linus decide.

So it's in 2.6.21-rc1.

Is it really so necessary in the linux-source?
Who suppose to track and update 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/

ioctls.h (Re: [PATCH][RFC] Make asm-generic/ioctl.h extensible by adding conditionals.)

[Oleg Verych]

> From: "Robert P. J. Day"
> Newsgroups: gmane.linux.kernel
> Subject: [PATCH][RFC] Make asm-generic/ioctl.h extensible by adding 
> conditionals.
> Date: Sat, 24 Feb 2007 06:45:20 -0500 (EST)

>   as a followup to my earlier post, is it worth making this change to
> allow at least a couple arch-specific ioctl.h files to be massively
> simplified?

And i wonder, why there is no generic ioctls.h, hm?


-
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] USB Elan FTDI: check for workqueue creation v2

[Oleg Verych]

> From: Cyrill Gorcunov
> Newsgroups: gmane.linux.kernel
> Subject: bss zeroing ([PATCH] USB Elan FTDI: check for workqueue creation v2)
> Date: Sat, 24 Feb 2007 10:41:15 +0300
[]
> Btw, Pete, you are right! C99 ANSI standart says that static pointer
> if it not initialized explicitly has to be set to NULL by compiler ;)
> Thanks a lot for comments and Ack the patch please.

Are you sure about "by compiler"? I mean, why not by OS, in case of uCs
by code/data memory image generator?


-
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/