Re: #pragma once (was Re: incoming)

[Al Viro]

On Sat, Feb 27, 2021 at 02:02:21AM +0300, Alexey Dobriyan wrote:

> There are rules and schemes about how to create guard macro.
> 
> Should it be prefixed by underscore?
> Should it be prefixed by two underscores?
> Should it be full path uppercased or just last path component?
> Should the guard macro be lowercased?
> Should it be changed when header is moved?
> Should trailing #endif contain comment?
> Should #define be just #define or "#define FOO 1"?

Who cares?  To all of the above, really.

> I've even seen advice (or an IDE doing that) that is should contain
> timestamp of a header creation time to minimise collisions (implying
> collisions could happen as could typos as could broken guards)

Ever seen that in the tree?  Where, if so?

> All this zoo of styles and made up mental work is completely avoided
> by using #pragma once:
> 
>   1) put #pragma once on the first line
>   
>   or
> 
>   2) put #pragma once on the second line after SPDX banner
> 
> and that's it.
> 
> No fuss, no filled up preprocessor hashtables, no implicit arguing
> about styles.

Care to provide some stats on the amount of those macros encountered
on build, along with the total amount of defines parsed and hashed?
It's noise.

And what is "implicit arguing", BTW?  I'm yet to see any fights
along those lines - you are the first one to bring that up, AFAICS.
Maybe I'd simply been lucky until now, of course, but...

RE: #pragma once (was Re: incoming)

[David Laight]

From: Alexey Dobriyan 
> Sent: 26 February 2021 23:02
> 
> On Fri, Feb 26, 2021 at 01:53:48PM -0800, Linus Torvalds wrote:
> > On Fri, Feb 26, 2021 at 12:17 PM Alexey Dobriyan  
> > wrote:
> > >
> > > I want to sent treewide "#pragma once" conversion:
> >
> > Are there *any* advantages to it?
> >
> > It's non-standard,
> 
> It is effectively standard:
> https://en.wikipedia.org/wiki/Pragma_once#Portability

At the top of the page

In the C and C++ programming languages, pragma once is a non-standard but 
widely supported

So non-standard :-)

And #pragma is ugly...

There are also times when an include guard has to be set in order to stop
a problematic inner file being included.
Perhaps only during hacking, but it is useful.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: #pragma once (was Re: incoming)

[Alexey Dobriyan]

On Fri, Feb 26, 2021 at 01:53:48PM -0800, Linus Torvalds wrote:
> On Fri, Feb 26, 2021 at 12:17 PM Alexey Dobriyan  wrote:
> >
> > I want to sent treewide "#pragma once" conversion:
> 
> Are there *any* advantages to it?
> 
> It's non-standard,

It is effectively standard:
https://en.wikipedia.org/wiki/Pragma_once#Portability

and I'll spare UAPI headers from conversion.

> and the historical argument for it ("it can reduce
> compile times because the preprocessor doesn't open the file twice" is
> pure and utter hogwash. Any preprocessor worth its salt does the same
> thing for the standard and traditional #ifndef/#define guard sequence.
> 
> Honestly, "#pragma once" was always a hack for bad preprocessors that
> weren't smart enough to just figure it out from the regular guarding
> macros.
> 
> I can't imagine that any preprocessor that incompetent exists any
> more, and if i does, we sure shouldn't be using it.
> 
> So #pragma once seems to have no actual advantages.

The advantage is removing busywork that is include guards.

There are rules and schemes about how to create guard macro.

Should it be prefixed by underscore?
Should it be prefixed by two underscores?
Should it be full path uppercased or just last path component?
Should the guard macro be lowercased?
Should it be changed when header is moved?
Should trailing #endif contain comment?
Should #define be just #define or "#define FOO 1"?

I've even seen advice (or an IDE doing that) that is should contain
timestamp of a header creation time to minimise collisions (implying
collisions could happen as could typos as could broken guards)

All this zoo of styles and made up mental work is completely avoided
by using #pragma once:

1) put #pragma once on the first line

or

2) put #pragma once on the second line after SPDX banner

and that's it.

No fuss, no filled up preprocessor hashtables, no implicit arguing
about styles. And way less LOC:

18092 files changed, 18883 insertions(+), 99841 deletions(-)

Now if old school header guard is necessary it can be used like in
good old times.

Nobody would miss include guards.

Re: #pragma once (was Re: incoming)

[Linus Torvalds]

On Fri, Feb 26, 2021 at 12:17 PM Alexey Dobriyan  wrote:
>
> I want to sent treewide "#pragma once" conversion:

Are there *any* advantages to it?

It's non-standard, and the historical argument for it ("it can reduce
compile times because the preprocessor doesn't open the file twice" is
pure and utter hogwash. Any preprocessor worth its salt does the same
thing for the standard and traditional #ifndef/#define guard sequence.

Honestly, "#pragma once" was always a hack for bad preprocessors that
weren't smart enough to just figure it out from the regular guarding
macros.

I can't imagine that any preprocessor that incompetent exists any
more, and if i does, we sure shouldn't be using it.

So #pragma once seems to have no actual advantages.

   Linus

#pragma once (was Re: incoming)

[Alexey Dobriyan]

Linus wrote:

> I'm hoping to just do -rc1 this weekend after all - despite my late
> start due to loss of power for several days.
> 
> I'll allow late stragglers with good reason through, but the fewer of
> those there are, the better, of course.

I want to sent treewide "#pragma once" conversion:

18092 files changed, 18883 insertions(+), 99841 deletions(-)

ideally it is done as 1 commit avoiding my death by thousand cuts of
going through all of maintainers.

There may be a compile failure or two but the list of exceptions is
stable.

Opinions? :-)

Re: incoming

[Vlastimil Babka]

On 7/19/19 12:56 AM, Andrew Morton wrote:
> 
> The rest of MM and a kernel-wide procfs cleanup.
> 
> 
> 
> Summary of the more significant patches:

Thanks for that!

Perhaps now it would be nice if this went also to linux-mm and lkml, as
mm-commits is sort of hidden.

Vlastimil

Re: incoming

[Vlastimil Babka]

On 7/17/19 6:13 PM, Linus Torvalds wrote:
> On Wed, Jul 17, 2019 at 1:47 AM Vlastimil Babka  wrote:
>>
>> So I've tried now to provide an example what I had in mind, below.
> 
> I'll take it as a trial. I added one-line notes about coda and the
> PTRACE_GET_SYSCALL_INFO interface too.

Thanks.

> I do hope that eventually I'll just get pull requests,

Very much agree, that was also discussed at length in the LSF/MM mm
process session I've linked.

> and they'll
> have more of a "theme" than this all (*)

I'll check if the first patch bomb would be more amenable to that, as I
plan to fill in the mm part for 5.3 on LinuxChanges wiki, but for a
merge commit it's too late.

>Linus
> 
> (*) Although in many ways, the theme for Andrew is "falls through the
> cracks otherwise" so I'm not really complaining. This has been working
> for years and years.

Nevermind the misc stuff that much, but I think mm itself is more
important and deserves what other subsystems have.

Re: incoming

[Christian Brauner]

On Wed, Jul 17, 2019 at 09:13:26AM -0700, Linus Torvalds wrote:
> On Wed, Jul 17, 2019 at 1:47 AM Vlastimil Babka  wrote:
> >
> > So I've tried now to provide an example what I had in mind, below.
> 
> I'll take it as a trial. I added one-line notes about coda and the
> PTRACE_GET_SYSCALL_INFO interface too.
> 
> I do hope that eventually I'll just get pull requests, and they'll
> have more of a "theme" than this all (*)
> 
>Linus
> 
> (*) Although in many ways, the theme for Andrew is "falls through the
> cracks otherwise" so I'm not really complaining. This has been working

I put all pid{fd}/clone{3} which is mostly related to pid.c, exit.c,
fork.c into my tree and try to give it a consistent theme for the prs I
sent. And that at least from my perspective that worked and was pretty
easy to coordinate with Andrew. That should hopefully make it a little
easier to theme the -mm tree overall going forward.

Re: incoming

[Linus Torvalds]

On Wed, Jul 17, 2019 at 1:47 AM Vlastimil Babka  wrote:
>
> So I've tried now to provide an example what I had in mind, below.

I'll take it as a trial. I added one-line notes about coda and the
PTRACE_GET_SYSCALL_INFO interface too.

I do hope that eventually I'll just get pull requests, and they'll
have more of a "theme" than this all (*)

   Linus

(*) Although in many ways, the theme for Andrew is "falls through the
cracks otherwise" so I'm not really complaining. This has been working
for years and years.

Re: incoming

[Bhaskar Chowdhury]

Cool !! 


On 10:47 Wed 17 Jul , Vlastimil Babka wrote:

On 7/17/19 1:25 AM, Andrew Morton wrote:


Most of the rest of MM and just about all of the rest of everything
else.


Hi,

as I've mentioned at LSF/MM [1], I think it would be nice if mm pull
requests had summaries similar to other subsystems. I see they are now
more structured (thanks!), but they are now probably hitting the limit
of what scripting can do to produce a high-level summary for human
readers (unless patch authors themselves provide a blurb that can be
extracted later?).

So I've tried now to provide an example what I had in mind, below. Maybe
it's too concise - if there were "larger" features in this pull request,
they would probably benefit from more details. I'm CCing the known (to
me) consumers of these mails to judge :) Note I've only covered mm, and
core stuff that I think will be interesting to wide audience (change in
LIST_POISON2 value? I'm sure as hell glad to know about that one :)

Feel free to include this in the merge commit, if you find it useful.

Thanks,
Vlastimil

[1] https://lwn.net/Articles/787705/

-

- z3fold fixes and enhancements by Henry Burns and Vitaly Wool
- more accurate reclaimed slab caches calculations by Yafang Shao
- fix MAP_UNINITIALIZED UAPI symbol to not depend on config, by
Christoph Hellwig
- !CONFIG_MMU fixes by Christoph Hellwig
- new novmcoredd parameter to omit device dumps from vmcore, by Kairui Song
- new test_meminit module for testing heap and pagealloc initialization,
by Alexander Potapenko
- ioremap improvements for huge mappings, by Anshuman Khandual
- generalize kprobe page fault handling, by Anshuman Khandual
- device-dax hotplug fixes and improvements, by Pavel Tatashin
- enable synchronous DAX fault on powerpc, by Aneesh Kumar K.V
- add pte_devmap() support for arm64, by Robin Murphy
- unify locked_vm accounting with a helper, by Daniel Jordan
- several misc fixes

core/lib
- new typeof_member() macro including some users, by Alexey Dobriyan
- make BIT() and GENMASK() available in asm, by Masahiro Yamada
- changed LIST_POISON2 on x86_64 to 0xdead0122 for better code
generation, by Alexey Dobriyan
- rbtree code size optimizations, by Michel Lespinasse
- convert struct pid count to refcount_t, by Joel Fernandes

get_maintainer.pl
- add --no-moderated switch to skip moderated ML's, by Joe Perches




signature.asc
Description: PGP signature

Re: incoming

[Vlastimil Babka]

On 7/17/19 1:25 AM, Andrew Morton wrote:
> 
> Most of the rest of MM and just about all of the rest of everything
> else.

Hi,

as I've mentioned at LSF/MM [1], I think it would be nice if mm pull
requests had summaries similar to other subsystems. I see they are now
more structured (thanks!), but they are now probably hitting the limit
of what scripting can do to produce a high-level summary for human
readers (unless patch authors themselves provide a blurb that can be
extracted later?).

So I've tried now to provide an example what I had in mind, below. Maybe
it's too concise - if there were "larger" features in this pull request,
they would probably benefit from more details. I'm CCing the known (to
me) consumers of these mails to judge :) Note I've only covered mm, and
core stuff that I think will be interesting to wide audience (change in
LIST_POISON2 value? I'm sure as hell glad to know about that one :)

Feel free to include this in the merge commit, if you find it useful.

Thanks,
Vlastimil

[1] https://lwn.net/Articles/787705/

-

- z3fold fixes and enhancements by Henry Burns and Vitaly Wool
- more accurate reclaimed slab caches calculations by Yafang Shao
- fix MAP_UNINITIALIZED UAPI symbol to not depend on config, by
Christoph Hellwig
- !CONFIG_MMU fixes by Christoph Hellwig
- new novmcoredd parameter to omit device dumps from vmcore, by Kairui Song
- new test_meminit module for testing heap and pagealloc initialization,
by Alexander Potapenko
- ioremap improvements for huge mappings, by Anshuman Khandual
- generalize kprobe page fault handling, by Anshuman Khandual
- device-dax hotplug fixes and improvements, by Pavel Tatashin
- enable synchronous DAX fault on powerpc, by Aneesh Kumar K.V
- add pte_devmap() support for arm64, by Robin Murphy
- unify locked_vm accounting with a helper, by Daniel Jordan
- several misc fixes

core/lib
- new typeof_member() macro including some users, by Alexey Dobriyan
- make BIT() and GENMASK() available in asm, by Masahiro Yamada
- changed LIST_POISON2 on x86_64 to 0xdead0122 for better code
generation, by Alexey Dobriyan
- rbtree code size optimizations, by Michel Lespinasse
- convert struct pid count to refcount_t, by Joel Fernandes

get_maintainer.pl
- add --no-moderated switch to skip moderated ML's, by Joe Perches

Re: Incoming sms problem on Motorola Droid 4

[Tony Lindgren]

* Pavel Machek  [180508 21:53]:
> Hi!
> 
> I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> 
> > AT+CNMI=?
> < +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
> < OK
> ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
> ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> > AT+CNMI=1,2,2,1,0
> < OK
> ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0
> 
> ... unfortunately, with that configuration no messages are comming to
> ofono and the other phone sees them as "delievery failed".
> 
> I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
> PDU) messages. That works well enough for me.
> 
> Unfortunately, if I force ofono to pass "AT+CNMI=1,2", it does not
> work well, either.
> 
> Any ideas how to debug this / what to try?

Well you can try to see what Android is doing for SMS with:

# echo 0x7fff > /sys/module/ts27010mux/parameters/debug_level
# dmesg | grep ts27010 | grep AT

To send SMS, looks like Android RIL first does:

2 AT+CMGS=327 where 327 seems to be the size of the whatever
encoded message. Then the next packet to dlci 2 contains the
encoded message that is of size 327.

When receiving, mdm6600 sends these on dlci 1:
~+WAKEUP
~+WAKEUP
~+WAKEUP

Then mdm6600 sends this on dlci 9:
~+CMT=372

And that's probably the incoming SMS size. But I don't see
anything for what actually reads the incoming SMS.

Regards,

Tony

Re: Incoming sms problem on Motorola Droid 4

[Tony Lindgren]

* Pavel Machek  [180508 21:53]:
> Hi!
> 
> I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> 
> > AT+CNMI=?
> < +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
> < OK
> ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
> ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> > AT+CNMI=1,2,2,1,0
> < OK
> ofonod[3070]: src/network.c:__ofono_netreg_add_status_watch() 0x5bbbf0
> 
> ... unfortunately, with that configuration no messages are comming to
> ofono and the other phone sees them as "delievery failed".
> 
> I had some luck with unicsy_demo using AT+CNMI=1,2 with text mode (not
> PDU) messages. That works well enough for me.
> 
> Unfortunately, if I force ofono to pass "AT+CNMI=1,2", it does not
> work well, either.
> 
> Any ideas how to debug this / what to try?

Well you can try to see what Android is doing for SMS with:

# echo 0x7fff > /sys/module/ts27010mux/parameters/debug_level
# dmesg | grep ts27010 | grep AT

To send SMS, looks like Android RIL first does:

2 AT+CMGS=327 where 327 seems to be the size of the whatever
encoded message. Then the next packet to dlci 2 contains the
encoded message that is of size 327.

When receiving, mdm6600 sends these on dlci 1:
~+WAKEUP
~+WAKEUP
~+WAKEUP

Then mdm6600 sends this on dlci 9:
~+CMT=372

And that's probably the incoming SMS size. But I don't see
anything for what actually reads the incoming SMS.

Regards,

Tony

Re: incoming merge conflict to linux-next

[Stephen Rothwell]

Hi Chris,

On Wed, 18 May 2016 17:10:43 -0400 Chris Mason  wrote:
>
> Dave Sterba's tree in linux-next has a few btrfs patches that we're not
> sending yet into Linus.  We've got an update for Josef's enospc work
> that'll get sent in next week.
> 
> So he prepped a pull for me that merged up a number of his branches but
> didn't include Josef's new code.  It has all been in -next for some
> time, and then I put some fixes from Filipe on top.
> 
> Long story short, you'll get a merge conflict from my next branch:
> 
> https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git next
> 
> I've got the sample resolution in next-merge:
> 
> https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git next-merge
> 
> Please let us know if you have any problems.

A bit of a mess, but I sorted it out, thanks for the test merge.

-- 
Cheers,
Stephen Rothwell

Re: incoming merge conflict to linux-next

[Stephen Rothwell]

Hi Chris,

On Wed, 18 May 2016 17:10:43 -0400 Chris Mason  wrote:
>
> Dave Sterba's tree in linux-next has a few btrfs patches that we're not
> sending yet into Linus.  We've got an update for Josef's enospc work
> that'll get sent in next week.
> 
> So he prepped a pull for me that merged up a number of his branches but
> didn't include Josef's new code.  It has all been in -next for some
> time, and then I put some fixes from Filipe on top.
> 
> Long story short, you'll get a merge conflict from my next branch:
> 
> https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git next
> 
> I've got the sample resolution in next-merge:
> 
> https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git next-merge
> 
> Please let us know if you have any problems.

A bit of a mess, but I sorted it out, thanks for the test merge.

-- 
Cheers,
Stephen Rothwell

Re: incoming merge conflict to linux-next

[David Sterba]

On Wed, May 18, 2016 at 05:10:43PM -0400, Chris Mason wrote:
> Dave Sterba's tree in linux-next has a few btrfs patches that we're not
> sending yet into Linus.  We've got an update for Josef's enospc work
> that'll get sent in next week.
> 
> So he prepped a pull for me that merged up a number of his branches but
> didn't include Josef's new code.  It has all been in -next for some
> time, and then I put some fixes from Filipe on top.

JFYI, the enospc branch was not the way to Linus because there were some
unexpected warnings, the v2 patch update hasn't fixed them. So I won't
redo the for-chris branch yet, but will keep the enospc patchset in my
for-next for other testing.

Re: incoming merge conflict to linux-next

[David Sterba]

On Wed, May 18, 2016 at 05:10:43PM -0400, Chris Mason wrote:
> Dave Sterba's tree in linux-next has a few btrfs patches that we're not
> sending yet into Linus.  We've got an update for Josef's enospc work
> that'll get sent in next week.
> 
> So he prepped a pull for me that merged up a number of his branches but
> didn't include Josef's new code.  It has all been in -next for some
> time, and then I put some fixes from Filipe on top.

JFYI, the enospc branch was not the way to Linus because there were some
unexpected warnings, the v2 patch update hasn't fixed them. So I won't
redo the for-chris branch yet, but will keep the enospc patchset in my
for-next for other testing.

Re: incoming

[Rasmus Villemoes]

On Thu, Sep 10 2015, Linus Torvalds  wrote:

> The VERY FIRST conversion patch I looked at was buggy. That makes me
> angry. The whole *AND*ONLY* point of this whole thing was to get rid
> of bugs, and be a obviously safe interface, and then the first
> conversion patch proves it wrong.
>
> Let me show you:
>
> if (isdigit(*str)) {
> -   io_tlb_nslabs = simple_strtoul(str, , 0);
> +   str += parse_integer(str, 0, _tlb_nslabs);
>
> and obviously nobody spent even a *second* asking themselves "what if
> parse_integer returns an error".

[This is going to sound awfully self-glorifying. Oh well.] I did point
that out in another instance (memparse), which I think then got somewhat
fixed in a later version. Since Alexey and I seemed to disagree on what
guiding principles to use when doing the conversions and a number of
other points, I didn't have the energy to go through the entire series,
and the discussion died out.

http://thread.gmane.org/gmane.linux.kernel/1942623/focus=1944193

> I liked the automatic type-based templating it does, but I *don't*
> like the breakage that seems to be inevitable in any large-scale
> conversion from a previously used historical interface.

My words exactly.

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

Re: incoming

[Rasmus Villemoes]

On Thu, Sep 10 2015, Linus Torvalds  wrote:

> The VERY FIRST conversion patch I looked at was buggy. That makes me
> angry. The whole *AND*ONLY* point of this whole thing was to get rid
> of bugs, and be a obviously safe interface, and then the first
> conversion patch proves it wrong.
>
> Let me show you:
>
> if (isdigit(*str)) {
> -   io_tlb_nslabs = simple_strtoul(str, , 0);
> +   str += parse_integer(str, 0, _tlb_nslabs);
>
> and obviously nobody spent even a *second* asking themselves "what if
> parse_integer returns an error".

[This is going to sound awfully self-glorifying. Oh well.] I did point
that out in another instance (memparse), which I think then got somewhat
fixed in a later version. Since Alexey and I seemed to disagree on what
guiding principles to use when doing the conversions and a number of
other points, I didn't have the energy to go through the entire series,
and the discussion died out.

http://thread.gmane.org/gmane.linux.kernel/1942623/focus=1944193

> I liked the automatic type-based templating it does, but I *don't*
> like the breakage that seems to be inevitable in any large-scale
> conversion from a previously used historical interface.

My words exactly.

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

Re: incoming

[Linus Torvalds]

On Wed, Sep 9, 2015 at 3:34 PM, Andrew Morton  wrote:
> Subject: lib/: add parse_integer() (replacement for simple_strto*())
> Subject: parse_integer: add runtime testsuite
> Subject: parse-integer: rewrite kstrto*()
> Subject: parse_integer: add checkpatch.pl notice
> Subject: parse_integer: convert scanf()
> Subject: scanf: fix type range overflow
> Subject: parse_integer: convert lib/
> Subject: parse_integer: convert mm/
> Subject: parse_integer: convert fs/
> Subject: parse_integer: convert fs/cachefiles/
> Subject: parse_integer: convert ext2, ext4
> Subject: parse_integer: convert fs/ocfs2/
> Subject: parse_integer: convert fs/9p/
> Subject: parse_integer: convert fs/exofs/

No.

I'm not taking yet another broken "deprecate old interface, replace it
with new-and-improved one, and screw things up in the process".

The whole "kstrto*()" thing was a mistake. We had real bugs brought in
by the conversion to the "better" interface. The "even betterer" new
parse_integer() interface actually looks lik ea real improvement, and
talks about some of the brokenness of the old code, and I was really
wanting to like it, but then I saw the conversions.

The VERY FIRST conversion patch I looked at was buggy. That makes me
angry. The whole *AND*ONLY* point of this whole thing was to get rid
of bugs, and be a obviously safe interface, and then the first
conversion patch proves it wrong.

Let me show you:

if (isdigit(*str)) {
-   io_tlb_nslabs = simple_strtoul(str, , 0);
+   str += parse_integer(str, 0, _tlb_nslabs);

and obviously nobody spent even a *second* asking themselves "what if
parse_integer returns an error".

The old code didn't fail catastrophically in the error case. The new one does.

And yes, parse_integer() really can return an error, even despite that
"isdigit(*str)" check. Think about it. Or just read the source code.

I really am very tired indeed of these "trivially obvious
improvements" that are buggy and actually introduce whole new ways to
write buggy code. Yes, the old code could miss an error. But the old
code wouldn't then create invalid pointers like the new code does.

I'm not thrilled about going through the rest of this sequence,
looking for other gotcha's. But I am *really* really tired of this
idiotic "let's make up a new interface that gets things right" and
then absolutely doesn't get it right at all. This is not just an issue
for number parseing - we had similar issues with the completely
moronic and misdesigned crap called "strlcpy()", which was introduced
for similar reasons, and also caused nasty bugs where the old code was
actually correct, and the "converted to better and safer interfaces"
code was actually buggy.

Mixing the error handling and the string update was a mistake.
Although *not* mixing it causes its own set of problems.

But whatever the final resolution to this is, I am *not* taking this
series. No way, no how. I liked the automatic type-based templating it
does, but I *don't* like the breakage that seems to be inevitable in
any large-scale conversion from a previously used historical
interface. People who implement new and improved interfaces always
seem to get that wrong.

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

Re: incoming

[Linus Torvalds]

On Wed, Sep 9, 2015 at 3:34 PM, Andrew Morton  wrote:
> Subject: lib/: add parse_integer() (replacement for simple_strto*())
> Subject: parse_integer: add runtime testsuite
> Subject: parse-integer: rewrite kstrto*()
> Subject: parse_integer: add checkpatch.pl notice
> Subject: parse_integer: convert scanf()
> Subject: scanf: fix type range overflow
> Subject: parse_integer: convert lib/
> Subject: parse_integer: convert mm/
> Subject: parse_integer: convert fs/
> Subject: parse_integer: convert fs/cachefiles/
> Subject: parse_integer: convert ext2, ext4
> Subject: parse_integer: convert fs/ocfs2/
> Subject: parse_integer: convert fs/9p/
> Subject: parse_integer: convert fs/exofs/

No.

I'm not taking yet another broken "deprecate old interface, replace it
with new-and-improved one, and screw things up in the process".

The whole "kstrto*()" thing was a mistake. We had real bugs brought in
by the conversion to the "better" interface. The "even betterer" new
parse_integer() interface actually looks lik ea real improvement, and
talks about some of the brokenness of the old code, and I was really
wanting to like it, but then I saw the conversions.

The VERY FIRST conversion patch I looked at was buggy. That makes me
angry. The whole *AND*ONLY* point of this whole thing was to get rid
of bugs, and be a obviously safe interface, and then the first
conversion patch proves it wrong.

Let me show you:

if (isdigit(*str)) {
-   io_tlb_nslabs = simple_strtoul(str, , 0);
+   str += parse_integer(str, 0, _tlb_nslabs);

and obviously nobody spent even a *second* asking themselves "what if
parse_integer returns an error".

The old code didn't fail catastrophically in the error case. The new one does.

And yes, parse_integer() really can return an error, even despite that
"isdigit(*str)" check. Think about it. Or just read the source code.

I really am very tired indeed of these "trivially obvious
improvements" that are buggy and actually introduce whole new ways to
write buggy code. Yes, the old code could miss an error. But the old
code wouldn't then create invalid pointers like the new code does.

I'm not thrilled about going through the rest of this sequence,
looking for other gotcha's. But I am *really* really tired of this
idiotic "let's make up a new interface that gets things right" and
then absolutely doesn't get it right at all. This is not just an issue
for number parseing - we had similar issues with the completely
moronic and misdesigned crap called "strlcpy()", which was introduced
for similar reasons, and also caused nasty bugs where the old code was
actually correct, and the "converted to better and safer interfaces"
code was actually buggy.

Mixing the error handling and the string update was a mistake.
Although *not* mixing it causes its own set of problems.

But whatever the final resolution to this is, I am *not* taking this
series. No way, no how. I liked the automatic type-based templating it
does, but I *don't* like the breakage that seems to be inevitable in
any large-scale conversion from a previously used historical
interface. People who implement new and improved interfaces always
seem to get that wrong.

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

Re: incoming

[Roland McGrath]

> ABI changes are not a problem for -stable, so don't let that stop anyone
> :)

In fact this is the harmless sort (changes only the error code of a
failure case) that might actually go in if there were any important
reason.  But the smiley stands.


Thanks,
Roland
-
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: incoming

[Greg KH]

On Fri, May 04, 2007 at 11:57:21AM -0700, Roland McGrath wrote:
> > Ah.  The patch affects security code, but it doesn't actually address any
> > insecurity.  I didn't think it was needed for -stable?
> 
> I would not recommend it for -stable.  
> It is an ABI change for the case of a security refusal.

ABI changes are not a problem for -stable, so don't let that stop anyone
:)

thanks,

greg k-h
-
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: incoming

[Roland McGrath]

> Ah.  The patch affects security code, but it doesn't actually address any
> insecurity.  I didn't think it was needed for -stable?

I would not recommend it for -stable.  
It is an ABI change for the case of a security refusal.


Thanks,
Roland
-
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: incoming

[Greg KH]

On Fri, May 04, 2007 at 09:14:34AM -0700, Andrew Morton wrote:
> On Fri, 4 May 2007 06:37:28 -0700 Greg KH <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, May 02, 2007 at 03:02:52PM -0700, Andrew Morton wrote:
> > > - One little security patch
> > 
> > Care to cc: linux-stable with it so we can do a new 2.6.21 release with
> > it if needed?
> > 
> 
> Ah.  The patch affects security code, but it doesn't actually address any
> insecurity.  I didn't think it was needed for -stable?

Ah, ok, I read "security" as fixing a insecure problem, my mistake :)

thanks,

greg k-h
-
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: incoming

[Andrew Morton]

On Fri, 4 May 2007 06:37:28 -0700 Greg KH <[EMAIL PROTECTED]> wrote:

> On Wed, May 02, 2007 at 03:02:52PM -0700, Andrew Morton wrote:
> > - One little security patch
> 
> Care to cc: linux-stable with it so we can do a new 2.6.21 release with
> it if needed?
> 

Ah.  The patch affects security code, but it doesn't actually address any
insecurity.  I didn't think it was needed for -stable?



From: Roland McGrath <[EMAIL PROTECTED]>

wait* syscalls return -ECHILD even when an individual PID of a live child
was requested explicitly, when security_task_wait denies the operation. 
This means that something like a broken SELinux policy can produce an
unexpected failure that looks just like a bug with wait or ptrace or
something.

This patch makes do_wait return -EACCES (or other appropriate error returned
from security_task_wait() instead of -ECHILD if some children were ruled out
solely because security_task_wait failed.

[EMAIL PROTECTED]: switch error code to EACCES]
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Cc: Stephen Smalley <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: James Morris <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---

 kernel/exit.c |   17 +++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff -puN kernel/exit.c~return-eperm-not-echild-on-security_task_wait-failure 
kernel/exit.c
--- a/kernel/exit.c~return-eperm-not-echild-on-security_task_wait-failure
+++ a/kernel/exit.c
@@ -1033,6 +1033,8 @@ asmlinkage void sys_exit_group(int error
 
 static int eligible_child(pid_t pid, int options, struct task_struct *p)
 {
+   int err;
+
if (pid > 0) {
if (p->pid != pid)
return 0;
@@ -1066,8 +1068,9 @@ static int eligible_child(pid_t pid, int
if (delay_group_leader(p))
return 2;
 
-   if (security_task_wait(p))
-   return 0;
+   err = security_task_wait(p);
+   if (err)
+   return err;
 
return 1;
 }
@@ -1449,6 +1452,7 @@ static long do_wait(pid_t pid, int optio
DECLARE_WAITQUEUE(wait, current);
struct task_struct *tsk;
int flag, retval;
+   int allowed, denied;
 
add_wait_queue(>signal->wait_chldexit,);
 repeat:
@@ -1457,6 +1461,7 @@ repeat:
 * match our criteria, even if we are not able to reap it yet.
 */
flag = 0;
+   allowed = denied = 0;
current->state = TASK_INTERRUPTIBLE;
read_lock(_lock);
tsk = current;
@@ -1472,6 +1477,12 @@ repeat:
if (!ret)
continue;
 
+   if (unlikely(ret < 0)) {
+   denied = ret;
+   continue;
+   }
+   allowed = 1;
+
switch (p->state) {
case TASK_TRACED:
/*
@@ -1570,6 +1581,8 @@ check_continued:
goto repeat;
}
retval = -ECHILD;
+   if (unlikely(denied) && !allowed)
+   retval = denied;
 end:
current->state = TASK_RUNNING;
remove_wait_queue(>signal->wait_chldexit,);
_


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

[Greg KH]

On Wed, May 02, 2007 at 03:02:52PM -0700, Andrew Morton wrote:
> - One little security patch

Care to cc: linux-stable with it so we can do a new 2.6.21 release with
it if needed?

thanks,

greg k-h
-
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: incoming

[Greg KH]

On Wed, May 02, 2007 at 03:02:52PM -0700, Andrew Morton wrote:
 - One little security patch

Care to cc: linux-stable with it so we can do a new 2.6.21 release with
it if needed?

thanks,

greg k-h
-
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: incoming

[Andrew Morton]

On Fri, 4 May 2007 06:37:28 -0700 Greg KH [EMAIL PROTECTED] wrote:

 On Wed, May 02, 2007 at 03:02:52PM -0700, Andrew Morton wrote:
  - One little security patch
 
 Care to cc: linux-stable with it so we can do a new 2.6.21 release with
 it if needed?
 

Ah.  The patch affects security code, but it doesn't actually address any
insecurity.  I didn't think it was needed for -stable?



From: Roland McGrath [EMAIL PROTECTED]

wait* syscalls return -ECHILD even when an individual PID of a live child
was requested explicitly, when security_task_wait denies the operation. 
This means that something like a broken SELinux policy can produce an
unexpected failure that looks just like a bug with wait or ptrace or
something.

This patch makes do_wait return -EACCES (or other appropriate error returned
from security_task_wait() instead of -ECHILD if some children were ruled out
solely because security_task_wait failed.

[EMAIL PROTECTED]: switch error code to EACCES]
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
Cc: Stephen Smalley [EMAIL PROTECTED]
Cc: Chris Wright [EMAIL PROTECTED]
Cc: James Morris [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 kernel/exit.c |   17 +++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff -puN kernel/exit.c~return-eperm-not-echild-on-security_task_wait-failure 
kernel/exit.c
--- a/kernel/exit.c~return-eperm-not-echild-on-security_task_wait-failure
+++ a/kernel/exit.c
@@ -1033,6 +1033,8 @@ asmlinkage void sys_exit_group(int error
 
 static int eligible_child(pid_t pid, int options, struct task_struct *p)
 {
+   int err;
+
if (pid  0) {
if (p-pid != pid)
return 0;
@@ -1066,8 +1068,9 @@ static int eligible_child(pid_t pid, int
if (delay_group_leader(p))
return 2;
 
-   if (security_task_wait(p))
-   return 0;
+   err = security_task_wait(p);
+   if (err)
+   return err;
 
return 1;
 }
@@ -1449,6 +1452,7 @@ static long do_wait(pid_t pid, int optio
DECLARE_WAITQUEUE(wait, current);
struct task_struct *tsk;
int flag, retval;
+   int allowed, denied;
 
add_wait_queue(current-signal-wait_chldexit,wait);
 repeat:
@@ -1457,6 +1461,7 @@ repeat:
 * match our criteria, even if we are not able to reap it yet.
 */
flag = 0;
+   allowed = denied = 0;
current-state = TASK_INTERRUPTIBLE;
read_lock(tasklist_lock);
tsk = current;
@@ -1472,6 +1477,12 @@ repeat:
if (!ret)
continue;
 
+   if (unlikely(ret  0)) {
+   denied = ret;
+   continue;
+   }
+   allowed = 1;
+
switch (p-state) {
case TASK_TRACED:
/*
@@ -1570,6 +1581,8 @@ check_continued:
goto repeat;
}
retval = -ECHILD;
+   if (unlikely(denied)  !allowed)
+   retval = denied;
 end:
current-state = TASK_RUNNING;
remove_wait_queue(current-signal-wait_chldexit,wait);
_


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

[Greg KH]

On Fri, May 04, 2007 at 09:14:34AM -0700, Andrew Morton wrote:
 On Fri, 4 May 2007 06:37:28 -0700 Greg KH [EMAIL PROTECTED] wrote:
 
  On Wed, May 02, 2007 at 03:02:52PM -0700, Andrew Morton wrote:
   - One little security patch
  
  Care to cc: linux-stable with it so we can do a new 2.6.21 release with
  it if needed?
  
 
 Ah.  The patch affects security code, but it doesn't actually address any
 insecurity.  I didn't think it was needed for -stable?

Ah, ok, I read security as fixing a insecure problem, my mistake :)

thanks,

greg k-h
-
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: incoming

[Roland McGrath]

 Ah.  The patch affects security code, but it doesn't actually address any
 insecurity.  I didn't think it was needed for -stable?

I would not recommend it for -stable.  
It is an ABI change for the case of a security refusal.


Thanks,
Roland
-
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: incoming

[Greg KH]

On Fri, May 04, 2007 at 11:57:21AM -0700, Roland McGrath wrote:
  Ah.  The patch affects security code, but it doesn't actually address any
  insecurity.  I didn't think it was needed for -stable?
 
 I would not recommend it for -stable.  
 It is an ABI change for the case of a security refusal.

ABI changes are not a problem for -stable, so don't let that stop anyone
:)

thanks,

greg k-h
-
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: incoming

[Roland McGrath]

 ABI changes are not a problem for -stable, so don't let that stop anyone
 :)

In fact this is the harmless sort (changes only the error code of a
failure case) that might actually go in if there were any important
reason.  But the smiley stands.


Thanks,
Roland
-
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: incoming

[Andrew Morton]

On Thu, 3 May 2007 08:55:43 +0100 Russell King <[EMAIL PROTECTED]> wrote:

> On Wed, May 02, 2007 at 03:02:52PM -0700, Andrew Morton wrote:
> > So this is what I have lined up for the first mm->2.6.22 batch.  I won't be
> > sending it off for another 12-24 hours yet.  To give people time for final
> > comment and to give me time to see if it actually works.
> 
> I assume you're going to update this list with my comments I sent
> yesterday?
> 

Serial drivers?  Well you saw me drop a bunch of them.  I now have:

serial-driver-pmc-msp71xx.patch
rm9000-serial-driver.patch
serial-define-fixed_port-flag-for-serial_core.patch
mpsc-serial-driver-tx-locking.patch
serial-serial_core-use-pr_debug.patch

I'll also be holding off on MADV_FREE - Nick has some performance things to
share and I'm assuming they're not as good as he'd like.

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

[Russell King]

On Wed, May 02, 2007 at 03:02:52PM -0700, Andrew Morton wrote:
> So this is what I have lined up for the first mm->2.6.22 batch.  I won't be
> sending it off for another 12-24 hours yet.  To give people time for final
> comment and to give me time to see if it actually works.

I assume you're going to update this list with my comments I sent
yesterday?

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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: incoming

[Russell King]

On Wed, May 02, 2007 at 03:02:52PM -0700, Andrew Morton wrote:
 So this is what I have lined up for the first mm-2.6.22 batch.  I won't be
 sending it off for another 12-24 hours yet.  To give people time for final
 comment and to give me time to see if it actually works.

I assume you're going to update this list with my comments I sent
yesterday?

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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: incoming

[Andrew Morton]

On Thu, 3 May 2007 08:55:43 +0100 Russell King [EMAIL PROTECTED] wrote:

 On Wed, May 02, 2007 at 03:02:52PM -0700, Andrew Morton wrote:
  So this is what I have lined up for the first mm-2.6.22 batch.  I won't be
  sending it off for another 12-24 hours yet.  To give people time for final
  comment and to give me time to see if it actually works.
 
 I assume you're going to update this list with my comments I sent
 yesterday?
 

Serial drivers?  Well you saw me drop a bunch of them.  I now have:

serial-driver-pmc-msp71xx.patch
rm9000-serial-driver.patch
serial-define-fixed_port-flag-for-serial_core.patch
mpsc-serial-driver-tx-locking.patch
serial-serial_core-use-pr_debug.patch

I'll also be holding off on MADV_FREE - Nick has some performance things to
share and I'm assuming they're not as good as he'd like.

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

[Benjamin Herrenschmidt]

On Wed, 2007-05-02 at 15:02 -0700, Andrew Morton wrote:
> So this is what I have lined up for the first mm->2.6.22 batch.  I won't be
> sending it off for another 12-24 hours yet.  To give people time for final
> comment and to give me time to see if it actually works.

Thanks.

I have some powerpc bits that depend on that stuff that will go through
Paulus after these show up in git and I've rebased.

Cheers,
Ben.


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

[Benjamin Herrenschmidt]

On Wed, 2007-05-02 at 15:02 -0700, Andrew Morton wrote:
 So this is what I have lined up for the first mm-2.6.22 batch.  I won't be
 sending it off for another 12-24 hours yet.  To give people time for final
 comment and to give me time to see if it actually works.

Thanks.

I have some powerpc bits that depend on that stuff that will go through
Paulus after these show up in git and I've rebased.

Cheers,
Ben.


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

[Paul Jackson]

> Looks like Andrew's patch bomb script needs some rate limiting ;-)

sendpatchset has that, already builtin ;)

http://www.speakeasy.org/~pj99/sgi/sendpatchset

Though the 5 second delay might not be enough for someone
publishing at the rate Andrew does.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: incoming

[Paul Jackson]

Andrew wrote:
> I never got around to setting that up, plus the Subject:s pretty quickly
> become invisible when they're indented 198 columns in GUI MUAs.

My sendpatchset tool should be good for this.  It sends all but the
first message are sent in "Reference" to, and "In-Reply-To" the first
message.

  http://www.speakeasy.org/~pj99/sgi/sendpatchset

I use it when sending out multiple patches in sequence from a quilt
repository.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
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: incoming

[Paul Jackson]

Andrew wrote:
 I never got around to setting that up, plus the Subject:s pretty quickly
 become invisible when they're indented 198 columns in GUI MUAs.

My sendpatchset tool should be good for this.  It sends all but the
first message are sent in Reference to, and In-Reply-To the first
message.

  http://www.speakeasy.org/~pj99/sgi/sendpatchset

I use it when sending out multiple patches in sequence from a quilt
repository.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 
1.925.600.0401
-
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: incoming

[Paul Jackson]

 Looks like Andrew's patch bomb script needs some rate limiting ;-)

sendpatchset has that, already builtin ;)

http://www.speakeasy.org/~pj99/sgi/sendpatchset

Though the 5 second delay might not be enough for someone
publishing at the rate Andrew does.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 
1.925.600.0401
-
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: incoming

[Lee Revell]

On Thu, 2005-04-14 at 13:48 +0200, Geert Uytterhoeven wrote:
> On Tue, 12 Apr 2005, Andrew Morton wrote:
> > As the commits list probably isn't working at present I'll cc linux-kernel
> > on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
> > knowing what's hitting the main tree.
> 
> Is it me, or were really only 117 mails of the 198 sent to lkml?

The patch bombing seems to have really wedged vger.  It took up to 24
hours to get all the messages.

Looks like Andrew's patch bomb script needs some rate limiting ;-)

Lee

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

[Paulo Marques]

Geert Uytterhoeven wrote:
On Tue, 12 Apr 2005, Andrew Morton wrote:
As the commits list probably isn't working at present I'll cc linux-kernel
on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
knowing what's hitting the main tree.

Is it me, or were really only 117 mails of the 198 sent to lkml?
(?)
I just double-checked, and I can say that I received all 198 emails from 
vger...

--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
-
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: incoming

[Geert Uytterhoeven]

On Tue, 12 Apr 2005, Andrew Morton wrote:
> As the commits list probably isn't working at present I'll cc linux-kernel
> on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
> knowing what's hitting the main tree.

Is it me, or were really only 117 mails of the 198 sent to lkml?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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: incoming

[Geert Uytterhoeven]

On Tue, 12 Apr 2005, Andrew Morton wrote:
 As the commits list probably isn't working at present I'll cc linux-kernel
 on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
 knowing what's hitting the main tree.

Is it me, or were really only 117 mails of the 198 sent to lkml?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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: incoming

[Paulo Marques]

Geert Uytterhoeven wrote:
On Tue, 12 Apr 2005, Andrew Morton wrote:
As the commits list probably isn't working at present I'll cc linux-kernel
on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
knowing what's hitting the main tree.

Is it me, or were really only 117 mails of the 198 sent to lkml?
(?)
I just double-checked, and I can say that I received all 198 emails from 
vger...

--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
-
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: incoming

[Lee Revell]

On Thu, 2005-04-14 at 13:48 +0200, Geert Uytterhoeven wrote:
 On Tue, 12 Apr 2005, Andrew Morton wrote:
  As the commits list probably isn't working at present I'll cc linux-kernel
  on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
  knowing what's hitting the main tree.
 
 Is it me, or were really only 117 mails of the 198 sent to lkml?

The patch bombing seems to have really wedged vger.  It took up to 24
hours to get all the messages.

Looks like Andrew's patch bomb script needs some rate limiting ;-)

Lee

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

[Andrew Morton]

Russell King <[EMAIL PROTECTED]> wrote:
>
> I don't see a patch which adds linux/pm.h to linux/sysdev.h, which is
>  required to fix ARM builds in -rc2 and onwards kernels.

That fix is buried in [patch 105/198]
-
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: incoming

[Russell King]

On Tue, Apr 12, 2005 at 02:08:00PM -0700, Andrew Morton wrote:
> Russell King <[EMAIL PROTECTED]> wrote:
> >
> > I don't see a patch which adds linux/pm.h to linux/sysdev.h, which is
> >  required to fix ARM builds in -rc2 and onwards kernels.
> 
> That fix is buried in [patch 105/198]

Great, thanks.  I must have missed it, sorry.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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: incoming

[Russell King]

On Tue, Apr 12, 2005 at 03:23:22AM -0700, Andrew Morton wrote:
> As the commits list probably isn't working at present I'll cc linux-kernel
> on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
> knowing what's hitting the main tree.

I don't see a patch which adds linux/pm.h to linux/sysdev.h, which is
required to fix ARM builds in -rc2 and onwards kernels.

It is my understanding that you have such a patch, and if it isn't
going to be sent, I'd like to send my own fix so that ARM can start
building again in mainline.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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: incoming

[Matthias Urlichs]

Hi,   Andrew Morton schrub am Tue, 12 Apr 2005 04:10:45 -0700:

> David Vrabel <[EMAIL PROTECTED]> wrote:
>>
>> Is there any chance that in the future that these patch sets get posted
>>  all to one thread?
> 
> I never got around to setting that up, plus the Subject:s pretty quickly
> become invisible when they're indented 198 columns in GUI MUAs.
> 
Umm, what stops you from letting all the parts refer to part zero,
instead of part n-1?

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [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: incoming

[Chris Friesen]

Andrew Morton wrote:
As the commits list probably isn't working at present I'll cc linux-kernel
on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
knowing what's hitting the main tree.
I'd like to second the idea of having all the patches be replies to this 
original posting (ie one level of indenting for all patches).  That way 
a threaded view will only have one subject line for all 198 patches.

Chris
-
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: incoming

[David Vrabel]

Andrew Morton wrote:
> As the commits list probably isn't working at present I'll cc linux-kernel
> on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
> knowing what's hitting the main tree.

Is there any chance that in the future that these patch sets get posted
all to one thread?  Perhaps as a reply to a summary? 1 thread to ignore
is preferable to 198.

David Vrabel
-
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: incoming

[David Vrabel]

Andrew Morton wrote:
> David Vrabel <[EMAIL PROTECTED]> wrote:
> 
>>Is there any chance that in the future that these patch sets get posted
>> all to one thread?
> 
> I never got around to setting that up, plus the Subject:s pretty quickly
> become invisible when they're indented 198 columns in GUI MUAs.

I meant something like this:

[patch 000/100]  Foo-ize the baz.
   [patch 001/100] Frob the baz
   [patch 002/100] baz cleanups
   [patch 003/100] apply foo-ization to baz

Rather than

[patch 000/100] Foo-ize the baz.
   [patch 001/100] Frob the baz
 [patch 002/100] baz cleanups
   [patch 003/100] apply foo-ization to baz

Which would (as you rightly pointed out) be ludicrous.

i.e., all the patches are replys to the summary.

David Vrabel
-
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: incoming

[Andrew Morton]

David Vrabel <[EMAIL PROTECTED]> wrote:
>
> Is there any chance that in the future that these patch sets get posted
>  all to one thread?

I never got around to setting that up, plus the Subject:s pretty quickly
become invisible when they're indented 198 columns in GUI MUAs.

Hopefully we'll have the commits list running next time...
-
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: incoming

[Andrew Morton]

David Vrabel [EMAIL PROTECTED] wrote:

 Is there any chance that in the future that these patch sets get posted
  all to one thread?

I never got around to setting that up, plus the Subject:s pretty quickly
become invisible when they're indented 198 columns in GUI MUAs.

Hopefully we'll have the commits list running next time...
-
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: incoming

[David Vrabel]

Andrew Morton wrote:
 David Vrabel [EMAIL PROTECTED] wrote:
 
Is there any chance that in the future that these patch sets get posted
 all to one thread?
 
 I never got around to setting that up, plus the Subject:s pretty quickly
 become invisible when they're indented 198 columns in GUI MUAs.

I meant something like this:

[patch 000/100]  Foo-ize the baz.
   [patch 001/100] Frob the baz
   [patch 002/100] baz cleanups
   [patch 003/100] apply foo-ization to baz

Rather than

[patch 000/100] Foo-ize the baz.
   [patch 001/100] Frob the baz
 [patch 002/100] baz cleanups
   [patch 003/100] apply foo-ization to baz

Which would (as you rightly pointed out) be ludicrous.

i.e., all the patches are replys to the summary.

David Vrabel
-
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: incoming

[David Vrabel]

Andrew Morton wrote:
 As the commits list probably isn't working at present I'll cc linux-kernel
 on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
 knowing what's hitting the main tree.

Is there any chance that in the future that these patch sets get posted
all to one thread?  Perhaps as a reply to a summary? 1 thread to ignore
is preferable to 198.

David Vrabel
-
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: incoming

[Chris Friesen]

Andrew Morton wrote:
As the commits list probably isn't working at present I'll cc linux-kernel
on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
knowing what's hitting the main tree.
I'd like to second the idea of having all the patches be replies to this 
original posting (ie one level of indenting for all patches).  That way 
a threaded view will only have one subject line for all 198 patches.

Chris
-
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: incoming

[Matthias Urlichs]

Hi,   Andrew Morton schrub am Tue, 12 Apr 2005 04:10:45 -0700:

 David Vrabel [EMAIL PROTECTED] wrote:

 Is there any chance that in the future that these patch sets get posted
  all to one thread?
 
 I never got around to setting that up, plus the Subject:s pretty quickly
 become invisible when they're indented 198 columns in GUI MUAs.
 
Umm, what stops you from letting all the parts refer to part zero,
instead of part n-1?

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [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: incoming

[Russell King]

On Tue, Apr 12, 2005 at 03:23:22AM -0700, Andrew Morton wrote:
 As the commits list probably isn't working at present I'll cc linux-kernel
 on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
 knowing what's hitting the main tree.

I don't see a patch which adds linux/pm.h to linux/sysdev.h, which is
required to fix ARM builds in -rc2 and onwards kernels.

It is my understanding that you have such a patch, and if it isn't
going to be sent, I'd like to send my own fix so that ARM can start
building again in mainline.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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: incoming

[Russell King]

On Tue, Apr 12, 2005 at 02:08:00PM -0700, Andrew Morton wrote:
 Russell King [EMAIL PROTECTED] wrote:
 
  I don't see a patch which adds linux/pm.h to linux/sysdev.h, which is
   required to fix ARM builds in -rc2 and onwards kernels.
 
 That fix is buried in [patch 105/198]

Great, thanks.  I must have missed it, sorry.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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: incoming

[Andrew Morton]

Russell King [EMAIL PROTECTED] wrote:

 I don't see a patch which adds linux/pm.h to linux/sysdev.h, which is
  required to fix ARM builds in -rc2 and onwards kernels.

That fix is buried in [patch 105/198]
-
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: Incoming TCP TOS: A simple question, I would have thought...

[kuznet]

Hello!

> I've scrolled through various code in net/ipv4, and I can't see how to query 
> the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which
> initiated the connection).

No way. Formally it is IP_RECVTOS, followed by IP_PKTOPTIONS.
But getting TOS via IP_PKTOPTIONS is not implemented, only ttl.

Alexey
-
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: Incoming TCP TOS: A simple question, I would have thought...

[kuznet]

Hello!

 I've scrolled through various code in net/ipv4, and I can't see how to query 
 the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which
 initiated the connection).

No way. Formally it is IP_RECVTOS, followed by IP_PKTOPTIONS.
But getting TOS via IP_PKTOPTIONS is not implemented, only ttl.

Alexey
-
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: Incoming TCP TOS: A simple question, I would have thought...

[David Luyer]

> getsockopt(fd, SOL_IP, IP_TOS, ..

Doesn't work.  Returns the TOS of outgoing packets, which defaults to 0 even if
there is a TOS set on incoming traffic... that was what I tried in my first 
test program.

David.

> cheers,
> 
> lincoln.
> 
> At 03:00 PM 7/03/2001 +1100, David Luyer wrote:
> 
> >I've scrolled through various code in net/ipv4, and I can't see how to query
> >the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which
> >initiated the connection).
> >
> >Someone has sent in a feature request for squid which would require this,
> >presumably so they can set the TOS in their routers and have the squid caches
> >honour the TOS to select performance (via delay pools, multiple parents,
> >different outgoing IP or similar).  However I can't see how to get the TOS for
> >a TCP socket out of the kernel short of having an open raw socket watching for
> >SYNs and looking at the TOS on them.
> >
> >Any pointers?
> >
> >David.
-- 
David LuyerPhone:   +61 3 9674 7525
Engineering Projects Manager   P A C I F I C   Fax: +61 3 9699 8693
Pacific Internet (Australia)  I N T E R N E T  Mobile:  +61 4  2983
http://www.pacific.net.au/ NASDAQ:  PCNTF


-
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: Incoming TCP TOS: A simple question, I would have thought...

[Lincoln Dale]

getsockopt(fd, SOL_IP, IP_TOS, ..


cheers,

lincoln.

At 03:00 PM 7/03/2001 +1100, David Luyer wrote:

>I've scrolled through various code in net/ipv4, and I can't see how to query
>the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which
>initiated the connection).
>
>Someone has sent in a feature request for squid which would require this,
>presumably so they can set the TOS in their routers and have the squid caches
>honour the TOS to select performance (via delay pools, multiple parents,
>different outgoing IP or similar).  However I can't see how to get the TOS for
>a TCP socket out of the kernel short of having an open raw socket watching for
>SYNs and looking at the TOS on them.
>
>Any pointers?
>
>David.
>--
>David LuyerPhone:   +61 3 9674 7525
>Engineering Projects Manager   P A C I F I C   Fax: +61 3 9699 8693
>Pacific Internet (Australia)  I N T E R N E T  Mobile:  +61 4  2983
>http://www.pacific.net.au/ NASDAQ:  PCNTF
>
>
>-
>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/

-
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: Incoming TCP TOS: A simple question, I would have thought...

[David Luyer]

 getsockopt(fd, SOL_IP, IP_TOS, ..

Doesn't work.  Returns the TOS of outgoing packets, which defaults to 0 even if
there is a TOS set on incoming traffic... that was what I tried in my first 
test program.

David.

 cheers,
 
 lincoln.
 
 At 03:00 PM 7/03/2001 +1100, David Luyer wrote:
 
 I've scrolled through various code in net/ipv4, and I can't see how to query
 the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which
 initiated the connection).
 
 Someone has sent in a feature request for squid which would require this,
 presumably so they can set the TOS in their routers and have the squid caches
 honour the TOS to select performance (via delay pools, multiple parents,
 different outgoing IP or similar).  However I can't see how to get the TOS for
 a TCP socket out of the kernel short of having an open raw socket watching for
 SYNs and looking at the TOS on them.
 
 Any pointers?
 
 David.
-- 
David LuyerPhone:   +61 3 9674 7525
Engineering Projects Manager   P A C I F I C   Fax: +61 3 9699 8693
Pacific Internet (Australia)  I N T E R N E T  Mobile:  +61 4  2983
http://www.pacific.net.au/ NASDAQ:  PCNTF


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