Those ruddy punctuation fixes

Those ruddy punctuation fixes

[Russell King]

Could we stop fix^wbreaking this stuff please.  GCC 3.2.2:

  arm-linux-gcc -Wp,-MD,arch/arm/kernel/.asm-offsets.s.d -D__KERNEL__ -Iinclude
-Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mapcs-32 -D__LINUX_ARM_ARCH__=4
-march=armv4 -mtune=strongarm110 -mshort-load-bytes -msoft-float -Wa,-mno-fpu -Uarm -nostdinc -iwithprefix include    -DKBUILD_BASENAME=asm_offsets -DKBUILD_MODNAME=asm_offsets -S -o arch/arm/kernel/asm-offsets.s arch/arm/kernel/asm-offsets.c
In file included from include/asm/system.h:28,
                 from include/asm/bitops.h:22,
                 from include/linux/bitops.h:3,
                 from include/linux/thread_info.h:20,
                 from include/linux/spinlock.h:12,
                 from include/linux/capability.h:44,
                 from include/linux/sched.h:7,
                 from arch/arm/kernel/asm-offsets.c:15:
include/asm/proc-fns.h:128:39: missing terminating ' character

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Those ruddy punctuation fixes

[John Bradford]

> Could we stop fix^wbreaking this stuff please.  GCC 3.2.2:
> 
> include/asm/proc-fns.h:128:39: missing terminating ' character

Ah, but the 'real' fix is to never use a word which requires an
apostrophe - E.G.

I can't apply this patch -> I can not apply this patch
Russell's patch -> The patch which Russell wrote

:-)

John.

Re: Those ruddy punctuation fixes

[Mike Dresser]

On Wed, 5 Mar 2003, John Bradford wrote:

> Ah, but the 'real' fix is to never use a word which requires an
> apostrophe - E.G.
>
> I can't apply this patch -> I can not apply this patch
> Russell's patch -> The patch which Russell wrote

Thank you, Commandar Data.

(although he seems to have picked up the ability to use them later in the
series)

:D

Re: Those ruddy punctuation fixes

[jw schultz]

On Wed, Mar 05, 2003 at 11:22:12AM +0000, John Bradford wrote:
> > Could we stop fix^wbreaking this stuff please.  GCC 3.2.2:
> > 
> > include/asm/proc-fns.h:128:39: missing terminating ' character
> 
> Ah, but the 'real' fix is to never use a word which requires an
> apostrophe - E.G.
> 
> I can't apply this patch -> I can not apply this patch

I can not apply this patch == I am able to not apply this patch
I cannot apply this patch ==  I am not able to apply this patch

If you are going to correct something be careful of changes
in meaning.

> Russell's patch -> The patch which Russell wrote

Assumes data not in evidence.  Russel might have composited
the patch.  Try "The patch from Russel" or "The patch Russel
provided"  I would honestly be willing to have just "Russels
Patch", "Russel patch" or "patch a la Russel" to evade the
tortured language for avoiding the possesive.

In any case, if it doesn't make the text more clear what is
the point?


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: Those ruddy punctuation fixes

[Russell King]

On Wed, Mar 05, 2003 at 05:50:27PM -0800, jw schultz wrote:
> > Russell's patch -> The patch which Russell wrote
> 
> Assumes data not in evidence.  Russel might have composited
> the patch.  Try "The patch from Russel" or "The patch Russel
> provided"  I would honestly be willing to have just "Russels
> Patch", "Russel patch" or "patch a la Russel" to evade the
> tortured language for avoiding the possesive.

And on the subject of spelling fixes, can I call you j schult? 8)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Those ruddy punctuation fixes

[John Bradford]

> > Russell's patch -> The patch which Russell wrote
> 
> Assumes data not in evidence.  Russel might have composited
> the patch.  Try "The patch from Russel" or "The patch Russel
> provided"  I would honestly be willing to have just "Russels
> Patch", "Russel patch" or "patch a la Russel" to evade the
> tortured language for avoiding the possesive.
> 
> In any case, if it doesn't make the text more clear what is
> the point?

Err, it was a joke :-)

John.

Re: Those ruddy punctuation fixes

[Dave Jones]

On Wed, Mar 05, 2003 at 11:10:15AM +0000, Russell King wrote:

 > Could we stop fix^wbreaking this stuff please.  GCC 3.2.2:
 > ...
 > include/asm/proc-fns.h:128:39: missing terminating ' character

100% agreed. People really are going too far IMO.
Given that most people will never read those comments, the
effort would be much better spent proof-reading/correcting
documentation than comments.

The "its just a spelling mistake, it cant break the build!"
mantra is also way off base. If you touch a .c/.h file, you
introduce the possibility of breakage.

The cant -> can't pedantry is an example of just how extremely
silly these are getting. Is there really someone who sees
"cant" and doesn't understand what it could mean?
It just pedantic masturbation AFAICS.

		Dave

good info on memory management

[Prasad Kamath]

Hi All,
       Where can I get a full documentation on the memory management (for 
linux)?


thanks & regards
Prasad Kamath

Re: good info on memory management

[Terje Eggestad]

There was a guy who had done this thesis on documenting the Linux VM. He
posted an announcement on this list, I think it was in last dec
sometime. Check the archive.


On Wed, 2003-03-05 at 12:37, Prasad Kamath wrote:
> Hi All,
>        Where can I get a full documentation on the memory management (for 
> linux)?
> 
> 
> thanks & regards
> Prasad Kamath
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
_________________________________________________________________________

Terje Eggestad                  mailto:terje.eggestad@scali.no
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
N-0619 Oslo                     fax:    +47 22 62 89 51
NORWAY            
_________________________________________________________________________

Re: good info on memory management

[Ranjeet Shetye]

On Wed, 2003-03-05 at 13:03, Terje Eggestad wrote:
> There was a guy who had done this thesis on documenting the Linux VM. He
> posted an announcement on this list, I think it was in last dec
> sometime. Check the archive.
> 
> 
> On Wed, 2003-03-05 at 12:37, Prasad Kamath wrote:
> > Hi All,
> >        Where can I get a full documentation on the memory management (for 
> > linux)?
> > 
> > 
> > thanks & regards
> > Prasad Kamath
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> -- 
> _________________________________________________________________________
> 
> Terje Eggestad                  mailto:terje.eggestad@scali.no
> Scali Scalable Linux Systems    http://www.scali.com
> 
> Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
> P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
> N-0619 Oslo                     fax:    +47 22 62 89 51
> NORWAY            
> _________________________________________________________________________
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Mel Gorman's thesis. He is/was at Univerisity of Limerick, Ireland. URL
does not always seem to work - sometimes it goes down and comes up a bit
later. Has happened twice to me.

"
The documentation comes in two parts. The first is "Understanding the
Linux Virtual Memory Manager" and it does pretty much as described. It
is available in three formats, PDF, HTML and plain text.

Understanding the Linux Virtual Memory Manager
PDF: http://www.csn.ul.ie/~mel/projects/vm/guide/pdf/understand.pdf
HTML: http://www.csn.ul.ie/~mel/projects/vm/guide/html/understand/
Text: http://www.csn.ul.ie/~mel/projects/vm/guide/text/understand.txt

The second part is a code commentary which is literally a guided tour
through the code. It is intended to help decipher the more cryptic
sections as well as identify the code patterns that are prevalent
through the code. I decided to have the code separate from the first
document as maintaining the code in the document would be too painful

Code Commentary on the Linux Virtual Memory Manager
PDF: http://www.csn.ul.ie/~mel/projects/vm/guide/pdf/code.pdf
HTML: http://www.csn.ul.ie/~mel/projects/vm/guide/html/code
Text: http://www.csn.ul.ie/~mel/projects/vm/guide/text/code.txt

Any feedback, comments or suggestions are welcome from anyone with a VM
interest but I would appreciate if people already familiar with the VM
would even give a brief read to check for technical accuracy. There was
rarely an authoritative source to check to make sure I was right and I
didn't want to be asking questions every 5 minutes on IRC or mailing
lists :-) 
"

-- 
Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
Ranjeet dot Shetye2 at Zultys dot com
http://www.zultys.com/

The views, opinions, and judgements expressed in this message are solely
those of
the author. The message contents have not been reviewed or approved by
Zultys.

Re: Those ruddy punctuation fixes

[Steven Cole]

On Wed, 2003-03-05 at 05:20, Dave Jones wrote:
> On Wed, Mar 05, 2003 at 11:10:15AM +0000, Russell King wrote:
> 
>  > Could we stop fix^wbreaking this stuff please.  GCC 3.2.2:
>  > ...
>  > include/asm/proc-fns.h:128:39: missing terminating ' character
> 
> 100% agreed. People really are going too far IMO.
> Given that most people will never read those comments, the
> effort would be much better spent proof-reading/correcting
> documentation than comments.
> 
> The "its just a spelling mistake, it cant break the build!"
> mantra is also way off base. If you touch a .c/.h file, you
> introduce the possibility of breakage.

That is why I was very careful with my its -> it's patch.
In the two files where an extra apostrophe would have broken
the build, I changed its to it is.  Why not just leave it alone?
Because some well-meaning spelling fixer may come along in the
future and break it, just like in proc-fns.h.

> 
> The cant -> can't pedantry is an example of just how extremely
> silly these are getting. Is there really someone who sees
> "cant" and doesn't understand what it could mean?
> It just pedantic masturbation AFAICS.
> 
> 		Dave

It's too bad that the cant -> can't change is tarred with the same brush
as thresold -> threshold and asociation -> association.  My belief is
that those kind of fixes have these benefits:

The comments are more readable.
The source can be grepped more accurately.
Correct spelling sets a good example.
Incorrect spelling sets a bad example and proliferates.

Why all the fixes now?  Because it's a window of opportunity. Linus
seems more comfortable with accepting these kind of changes now than at
other times.

If we don't get these changes in now, expect to have this same
conversation around 2.9.50 or so. (Assuming that 3.0 will follow 2.6)

Cheers,
Steven 

Re: Those ruddy punctuation fixes

[Val Henson]

On Wed, Mar 05, 2003 at 08:11:11PM -0700, Steven Cole wrote:
> 
> That is why I was very careful with my its -> it's patch.
> In the two files where an extra apostrophe would have broken
> the build, I changed its to it is.  Why not just leave it alone?
> Because some well-meaning spelling fixer may come along in the
> future and break it, just like in proc-fns.h.

Wait, this sounds like a conversation with the Mafia:

"Pay us protection money."
"Why do we need to pay you for protection?"
"So we can protect you from criminals like ourselves."

I'd rather solve this problem by making standalone spelling fixes and
other cosmetic changes taboo.  Cosmetic changes combined with actual
useful code changes are fine with me.  If you're risking breaking the
build, there should be some benefit that justifies the risk.

Consider this a vote against standalone spelling/typo patches.

-VAL (normally a total pedant about spelling and grammar)

Re: Those ruddy punctuation fixes

[Steven Cole]

On Thu, 2003-03-06 at 18:04, Val Henson wrote:
> On Wed, Mar 05, 2003 at 08:11:11PM -0700, Steven Cole wrote:
> > 
> > That is why I was very careful with my its -> it's patch.
> > In the two files where an extra apostrophe would have broken
> > the build, I changed its to it is.  Why not just leave it alone?
> > Because some well-meaning spelling fixer may come along in the
> > future and break it, just like in proc-fns.h.
> 
> Wait, this sounds like a conversation with the Mafia:
> 
> "Pay us protection money."
> "Why do we need to pay you for protection?"
> "So we can protect you from criminals like ourselves."

That's a ridiculous comparison and it weakens your argument.  Leaving a
potential problem in place rather than fixing it as I did would be the
passive-aggressive approach, not the other way around.

> 
> I'd rather solve this problem by making standalone spelling fixes and
> other cosmetic changes taboo.  Cosmetic changes combined with actual
> useful code changes are fine with me.  If you're risking breaking the
> build, there should be some benefit that justifies the risk.

Breaking the build is a low probability (many hundreds of fixes and one 
build break AFAIK) and low consequence failure (a build fix of that
nature is obvious and quickly and easily done).

> 
> Consider this a vote against standalone spelling/typo patches.
> 
> -VAL (normally a total pedant about spelling and grammar)

The more persuasive argument against tree-wide fixes has been made by
Dave Jones, who has been slowed down by having to reconcile his external
patches with these changes.  For that reason, I've suggested that
maintainers use Dan Kegel's scripts to clean up their own areas when the
time is right for them.  But the maintainers have better things to do
with their time that this kind of low priority work. So chances are that
the spelling fix situation will go back into hibernation for another
release cycle, which I'm sure will make a lot of people happy.

Steven

Re: Those ruddy punctuation fixes

[Martin J. Bligh]

>> Wait, this sounds like a conversation with the Mafia:
>> 
>> "Pay us protection money."
>> "Why do we need to pay you for protection?"
>> "So we can protect you from criminals like ourselves."
> 
> That's a ridiculous comparison and it weakens your argument.  Leaving a

Reductio ad absurdum is often enlightening.

> potential problem in place rather than fixing it as I did would be the
> passive-aggressive approach, not the other way around.

But that's not exactly what you're doing - you're replacing one 
(very small) problem with another (very real) problem, the breakage 
of people's patches. Fixing up patches because of spelling
errors is a total waste of developer's time.

>> I'd rather solve this problem by making standalone spelling fixes and
>> other cosmetic changes taboo.  Cosmetic changes combined with actual
>> useful code changes are fine with me.  If you're risking breaking the
>> build, there should be some benefit that justifies the risk.
> 
> Breaking the build is a low probability (many hundreds of fixes and one 
> build break AFAIK) and low consequence failure (a build fix of that
> nature is obvious and quickly and easily done).

Breaking the build is indeed a low probability (assuming you compile
test your tree). Breaking other people's patches is a high probablility.

M.

Re: Those ruddy punctuation fixes

[Steven Cole]

On Thu, 2003-03-06 at 20:33, Martin J. Bligh wrote:
> >> Wait, this sounds like a conversation with the Mafia:
> >> 
> >> "Pay us protection money."
> >> "Why do we need to pay you for protection?"
> >> "So we can protect you from criminals like ourselves."
> > 
> > That's a ridiculous comparison and it weakens your argument.  Leaving a
> 
> Reductio ad absurdum is often enlightening.
> 
> > potential problem in place rather than fixing it as I did would be the
> > passive-aggressive approach, not the other way around.
> 
> But that's not exactly what you're doing - you're replacing one 
> (very small) problem with another (very real) problem, the breakage 
> of people's patches. Fixing up patches because of spelling
> errors is a total waste of developer's time.

Agreed.

> 
> >> I'd rather solve this problem by making standalone spelling fixes and
> >> other cosmetic changes taboo.  Cosmetic changes combined with actual
> >> useful code changes are fine with me.  If you're risking breaking the
> >> build, there should be some benefit that justifies the risk.
> > 
> > Breaking the build is a low probability (many hundreds of fixes and one 
> > build break AFAIK) and low consequence failure (a build fix of that
> > nature is obvious and quickly and easily done).
> 
> Breaking the build is indeed a low probability (assuming you compile
> test your tree). Breaking other people's patches is a high probablility.

So another approach to this is to offer cleanup services to willing
maintainers who don't have the time to do it themselves.  If anyone
wants their section of the tree spell-corrected, I can do that with the
help of Dan's scripts (the easy part), and review the resulting diff for
inappropriate fixes (broken puns, changed meaning, broken compiles),
send that around to a small group (the spelling police squad) for
further review, and then send it back to the requesting maintainer, who
can /dev/null it entirely, or hack it up to his delight before sending
it Linuswards.

How's that?

Steven

Re: Those ruddy punctuation fixes

[Martin J. Bligh]

>> Breaking the build is indeed a low probability (assuming you compile
>> test your tree). Breaking other people's patches is a high probablility.
> 
> So another approach to this is to offer cleanup services to willing
> maintainers who don't have the time to do it themselves.  If anyone
> wants their section of the tree spell-corrected, I can do that with the
> help of Dan's scripts (the easy part), and review the resulting diff for
> inappropriate fixes (broken puns, changed meaning, broken compiles),
> send that around to a small group (the spelling police squad) for
> further review, and then send it back to the requesting maintainer, who
> can /dev/null it entirely, or hack it up to his delight before sending
> it Linuswards.
> 
> How's that?

Sounds great to me, at least ;-)

M.

Re: Those ruddy punctuation fixes

[Hans Reiser]

You are fixing things and people are giving you shit for it.  People who 
want evidence that making something better is worth doing before they do 
it are....  Sigh.  In the unlikely event that Linus doesn't take your 
fixes directly, I'll take them for reiserfs, just let me know.  ReiserFS 
code is as good as we know how to make it, as a matter of policy, and 
that includes the comments.

-- 
Hans

Re: Those ruddy punctuation fixes

[Pete Zaitcev]

> I'd rather solve this problem by making standalone spelling fixes and
> other cosmetic changes taboo.  Cosmetic changes combined with actual
> useful code changes are fine with me.  If you're risking breaking the
> build, there should be some benefit that justifies the risk.

I generally reject combined patches which clean up and
change functions in places I maintain. The cleanup garbage
makes reviewing harder.

-- Pete

Re: good info on memory management

[Bongani Hlope]

> Hi All,
>        Where can I get a full documentation on the memory management (for 
> linux)?
> 
> 
> thanks & regards
> Prasad Kamath
> 

Take a look at http://www.csn.ul.ie/~mel/projects/vm/

Cheers

---------------------------------------------
This message was sent using M-Web Airmail - JUST LIKE THAT
M-Web: S.A.'s most trusted and reliable Internet Service Provider.
http://airmail.mweb.co.za/

Re: good info on memory management

[pd dd]

this is an interesting document. do you know anything
similar to this for kernel VFS?

thanks
parviz
--- Bongani Hlope <bonganilinux@mweb.co.za> wrote:
> > Hi All,
> >        Where can I get a full documentation on the
> memory management (for 
> > linux)?
> > 
> > 
> > thanks & regards
> > Prasad Kamath
> > 
> 
> Take a look at
> http://www.csn.ul.ie/~mel/projects/vm/
> 
> Cheers
> 
> ---------------------------------------------
> This message was sent using M-Web Airmail - JUST
> LIKE THAT
> M-Web: S.A.'s most trusted and reliable Internet
> Service Provider.
> http://airmail.mweb.co.za/
> 
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: good info on memory management

[Randy.Dunlap]

On Wed, 5 Mar 2003 09:12:37 -0800 (PST)
pd dd <parviz_kernel@yahoo.com> wrote:

| this is an interesting document. do you know anything
| similar to this for kernel VFS?
| 
| thanks
| parviz
| --- Bongani Hlope <bonganilinux@mweb.co.za> wrote:
| > > Hi All,
| > >        Where can I get a full documentation on the
| > memory management (for 
| > > linux)?
| > > 
| > > 
| > > thanks & regards
| > > Prasad Kamath
| > > 
| > 
| > Take a look at
| > http://www.csn.ul.ie/~mel/projects/vm/


See the collection of linux filesystem user and implementation URLs
at <http://www.xenotime.net/linux/linux-fs.html>.
Updates welcome.

--
~Randy