Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target
On Sat, 21 Jul 2007, Mike Frysinger wrote: > On 7/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > On Sat, Jul 21, 2007 at 06:03:00PM -0400, Mike Frysinger wrote: > > > On 7/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > > >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. > > > > > > > >A sinlge dedicated program that contian the sum of the functionality > > > >would > > > >be faster too. > > > > > > which functionality ? normalizing of whitespace or all these > > > linux-specific hacks ? unifdef serves one specific function which is > > > stated in its manpage: remove preprocessor conditionals from code. > > > > At present the kernel has a private copy of unidef. So adjusting the > > private copy for the needs of the kernels seems like a god plan. > > didnt realize the kernel had integrated it since it didnt at first ... > so yeah, extending it however we see fit should be fine > -mike just for the entertainment value: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217840 rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target
On 7/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > On Sat, Jul 21, 2007 at 06:03:00PM -0400, Mike Frysinger wrote: > > On 7/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > >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. > > > > > >A sinlge dedicated program that contian the sum of the functionality would > > >be faster too. > > > > which functionality ? normalizing of whitespace or all these > > linux-specific hacks ? unifdef serves one specific function which is > > stated in its manpage: remove preprocessor conditionals from code. > > At present the kernel has a private copy of unidef. So adjusting the > private copy for the needs of the kernels seems like a god plan. didnt realize the kernel had integrated it since it didnt at first ... so yeah, extending it however we see fit should be fine -mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target
On Sat, Jul 21, 2007 at 06:03:00PM -0400, Mike Frysinger wrote: > On 7/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > >On Sat, Jul 21, 2007 at 03:21:43PM -0400, Mike Frysinger wrote: > >> On 7/21/07, Oleg Verych <[EMAIL PROTECTED]> wrote: > >> >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. > >> > >> 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 > >> > >> 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. > > > >A sinlge dedicated program that contian the sum of the functionality would > >be faster too. > > which functionality ? normalizing of whitespace or all these > linux-specific hacks ? unifdef serves one specific function which is > stated in its manpage: remove preprocessor conditionals from code. At present the kernel has a private copy of unidef. So adjusting the private copy for the needs of the kernels seems like a god plan. We could even make it an extension so we do not break current functionality. Sam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target
On 7/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > On Sat, Jul 21, 2007 at 03:21:43PM -0400, Mike Frysinger wrote: > > On 7/21/07, Oleg Verych <[EMAIL PROTECTED]> wrote: > > >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. > > > > 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 > > > > 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. > > A sinlge dedicated program that contian the sum of the functionality would > be faster too. which functionality ? normalizing of whitespace or all these linux-specific hacks ? unifdef serves one specific function which is stated in its manpage: remove preprocessor conditionals from code. -mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target
On Sat, Jul 21, 2007 at 03:21:43PM -0400, Mike Frysinger wrote: > On 7/21/07, Oleg Verych <[EMAIL PROTECTED]> wrote: > >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. > > 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 > > 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. A sinlge dedicated program that contian the sum of the functionality would be faster too. Sam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target
On 7/21/07, Oleg Verych <[EMAIL PROTECTED]> wrote: > 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. 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 but again, if you feel that strongly about it, you're certainly free to post a patch -mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target
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. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target
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.
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kbuild-devel mailing list
kbuild-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target
On 7/21/07, Oleg Verych <[EMAIL PROTECTED]> wrote:
> * 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?
that is the definition of both + and \{1,\}
> > # 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?
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
> > + -e
> > "s/[[:space:]]__user[[:space:]]\{1,\}
>
> substitute one or more ' __user '
>
> > / /g" \
>
> with ' ', everywhere (flag 'g'). So, is it really needed that '\{' thing?
no, there is no grouping marker anywhere, so the match always applies
to just the whitespace
> > + -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.
a question that i think is really only relevant if it actually occurs
in the source code
> > -e "/^\#include /d"
> whitespace is allowed ^ here and is used for better readability
> sometimes.
so post a patch for inclusion ... not that it's been an actual problem
[yet] though
-mike
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kbuild-devel mailing list
kbuild-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target
* 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.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kbuild-devel mailing list
kbuild-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
