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 file
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
>
On 7/21/07, Oleg Verych <[EMAIL PROTECTED]> wrote:
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 cla
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 preproces
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
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 Frysi
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\+\)\}
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
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, t
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 li
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 use
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 la
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> Uhm, would not it be easier to just use 's/\b__user\b//g' ?
\b is not POSIX.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756
On Jul 21 2007 10:23, 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.
Uhm, would not
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
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.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Lin
* 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
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 equiv
18 matches
Mail list logo
