Re: A quick guide to why stand-alone checkpatch patches suck...

[John de la Garza]

On Wed, Sep 17, 2014 at 05:13:58PM +, Bruno Guedes Souto wrote:
> This was a great discussion, until you guys started feeding the troll again.

It seems like a lot of people here don't get it and continue to keep basically
repeating themselves.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Issues with Community

[nick]

On 14-09-17 02:59 PM, Sudip Mukherjee wrote:
> ___
>>> Kernelnewbies mailing list
>>> Kernelnewbies@kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> Sure I will look into linux-next issues later today.
>> Nick
>>
> you mean to say you have not yet seen linux-next?? but i remember seeing
> mails from you regarding git and linux-next..
> so this is another example of ignoring advices given to you.
> 
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
No I meant I will look into working on linux-next not about seeing it,
sorry my wording is causing confusion, if it is please let me known so
I can help you understand.
Nick 

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Issues with Community

[Jason Conklin]

First of all, if you missed my email on this topic (sent a few weeks ago),
please go read or reread it.[1] Things were relatively quiet on this
"front" until this week.

This is all my opinion (and I carry no clout here), but if you are
frustrated or annoyed by Nick's emails, the best thing you can do for him
and for this list is just to ignore them.

Correct me if I'm mistaken, but I don't think anyone is ~obligated~ to
review or respond to every patch, or think about every question raised --
and frankly, all this exasperation about Nick creates a lot more noise in
my inbox than the questions and patches themselves. And as a newbie myself,
I've actually learned a thing or two from it all.

I commend those of you who have continued to respond patiently to Nick, as
well as those who haven't banned him. I don't know that there is an ideal
short-term solution here, but I do notice that his input has changed
gradually over the past few months; I suspect that could continue.

Perhaps continued repetition of the idea that he set aside patch submission
as a goal and use bug reports as a way to explore and better understand the
kernel.

[1] http://

lists.kernelnewbies.org

/

pipermail

/

kernelnewbies

/2014-August/011895.

html

On Sep 17, 2014 3:00 PM, "Sudip Mukherjee" 
wrote:

> ___
> > > Kernelnewbies mailing list
> > > Kernelnewbies@kernelnewbies.org
> > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> > Sure I will look into linux-next issues later today.
> > Nick
> >
> you mean to say you have not yet seen linux-next?? but i remember seeing
> mails from you regarding git and linux-next..
> so this is another example of ignoring advices given to you.
>
> > ___
> > Kernelnewbies mailing list
> > Kernelnewbies@kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Issues with Community

[Sudip Mukherjee]

___
> > Kernelnewbies mailing list
> > Kernelnewbies@kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> Sure I will look into linux-next issues later today.
> Nick
>
you mean to say you have not yet seen linux-next?? but i remember seeing
mails from you regarding git and linux-next..
so this is another example of ignoring advices given to you.

> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Nick Krause]

On Wed, Sep 17, 2014 at 2:15 PM, Robert P. J. Day  wrote:
> On Wed, 17 Sep 2014, Nick Krause wrote:
>
>> ... like to improve my rep with a tutor or someone who is willing to
>> be my router to the community  ...
>
>   there is no sane human being that would offer to be a tutor or
> mentor (a request you've made before) or "router" to someone who
> absolutely refuses to listen to the advice people give him.
>
>   you have absolutely no idea what mentoring involves, do you, nick?
> people offer to become mentors because they find up and coming folks
> who appear to be bright, ambitious and teachable, not irredeemably
> thick.
>
>   this *entire* *mailing* *list* has been trying to tutor or mentor
> you for the last two months, and it has been a colossal waste of time.
> where do you get the nerve to now ask for *personal* assistance, given
> that everyone knows you simply ignore whatever anyone tells you?
>
>   can we please, fer chrissake, just vote on a ban to get rid of nick
> and cut the nonsense on this mailing list by 90%? please?
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>
I am leaving for now and going to learn more about the kernel and come
back with some questions later.
Nick

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Robert P. J. Day]

On Wed, 17 Sep 2014, Nick Krause wrote:

> ... like to improve my rep with a tutor or someone who is willing to
> be my router to the community  ...

  there is no sane human being that would offer to be a tutor or
mentor (a request you've made before) or "router" to someone who
absolutely refuses to listen to the advice people give him.

  you have absolutely no idea what mentoring involves, do you, nick?
people offer to become mentors because they find up and coming folks
who appear to be bright, ambitious and teachable, not irredeemably
thick.

  this *entire* *mailing* *list* has been trying to tutor or mentor
you for the last two months, and it has been a colossal waste of time.
where do you get the nerve to now ask for *personal* assistance, given
that everyone knows you simply ignore whatever anyone tells you?

  can we please, fer chrissake, just vote on a ban to get rid of nick
and cut the nonsense on this mailing list by 90%? please?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Nick Krause]

e stranger on the internet is going to be your
tutor? Unless you belong to some minority, you shouldn't be waiting for
a tutor to take your hand and guide you... that's probably not going to
happen. Apply the advice that's been already given to you, e.g. read the
old mails and write each advice down. Until that, *please* lurk moar.

On Wed, Sep 17, 2014 at 2:01 PM, Philipp Muhoray
 wrote:
>
> Am 2014-09-17 19:47, schrieb Nick Krause:
>> On Wed, Sep 17, 2014 at 1:13 PM, Bruno Guedes Souto
>>  wrote:
>>> This was a great discussion, until you guys started feeding the troll again.
>>>
>>> Can we just stop feeding the troll? He will prob go way...
>>>
>>> If every *single* time that Nick posts something you reply to him it will 
>>> only
>>> lead to more replies from him saying he will get better, understand what he 
>>> is
>>> doing and that he wants to improve his rep with the community. That's his
>>> standard speech.
>>>
>>> BGS
>>>
>>>
>>> ___
>>> Kernelnewbies mailing list
>>> Kernelnewbies@kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbe stranger on the 
>>> internet is going to be your
tutor? Unless you belong to some minority, you shouldn't be waiting for
a tutor to take your hand and guide you... that's probably not going to
happen. Apply the advice that's been already given to you, e.g. read the
old mails and write each advice down. Until that, *please* lurk moar.
ies
>> Can I stop being called a troll. I am trying to learn here and improve
>> my rep and understanding of
>> the kernel. I would like to help but with this negative light around
>> me it is much more difficult and
>> hard to do. I understand the problems I have caused now and would like
>> to improve my rep with
>> a tutor or someone who is willing to be my router to the community
>> until I improve enough to a
>> member of the community on my own.
>> Thanks Nick
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> Why do you think that some stranger on the internet is going to be your
> tutor? Unless you belong to some minority, you shouldn't be waiting for
> a tutor to take your hand and guide you... that's probably not going to
> happen. Apply the advice that's been already given to you, e.g. read the
> old mails and write each advice down. Until that, *please* lurk moar.
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
That's what I plan to do now and ask many questions.
Nick

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Philipp Muhoray]

Am 2014-09-17 19:47, schrieb Nick Krause:
> On Wed, Sep 17, 2014 at 1:13 PM, Bruno Guedes Souto
>  wrote:
>> This was a great discussion, until you guys started feeding the troll again.
>>
>> Can we just stop feeding the troll? He will prob go way...
>>
>> If every *single* time that Nick posts something you reply to him it will 
>> only
>> lead to more replies from him saying he will get better, understand what he 
>> is
>> doing and that he wants to improve his rep with the community. That's his
>> standard speech.
>>
>> BGS
>>
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> Can I stop being called a troll. I am trying to learn here and improve
> my rep and understanding of
> the kernel. I would like to help but with this negative light around
> me it is much more difficult and
> hard to do. I understand the problems I have caused now and would like
> to improve my rep with
> a tutor or someone who is willing to be my router to the community
> until I improve enough to a
> member of the community on my own.
> Thanks Nick
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Why do you think that some stranger on the internet is going to be your 
tutor? Unless you belong to some minority, you shouldn't be waiting for 
a tutor to take your hand and guide you... that's probably not going to 
happen. Apply the advice that's been already given to you, e.g. read the 
old mails and write each advice down. Until that, *please* lurk moar.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Nick Krause]

On Wed, Sep 17, 2014 at 1:13 PM, Bruno Guedes Souto
 wrote:
> This was a great discussion, until you guys started feeding the troll again.
>
> Can we just stop feeding the troll? He will prob go way...
>
> If every *single* time that Nick posts something you reply to him it will only
> lead to more replies from him saying he will get better, understand what he is
> doing and that he wants to improve his rep with the community. That's his
> standard speech.
>
> BGS
>
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Can I stop being called a troll. I am trying to learn here and improve
my rep and understanding of
the kernel. I would like to help but with this negative light around
me it is much more difficult and
hard to do. I understand the problems I have caused now and would like
to improve my rep with
a tutor or someone who is willing to be my router to the community
until I improve enough to a
member of the community on my own.
Thanks Nick

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Bruno Guedes Souto]

This was a great discussion, until you guys started feeding the troll again.

Can we just stop feeding the troll? He will prob go way... 

If every *single* time that Nick posts something you reply to him it will only 
lead to more replies from him saying he will get better, understand what he is 
doing and that he wants to improve his rep with the community. That's his 
standard speech.

BGS


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Issues with Community

[Nick Krause]

On Wed, Sep 17, 2014 at 9:13 AM, Rik van Riel  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/16/2014 07:22 PM, nick wrote:
>> After numerous tries at good patches and still failing , I am
>> listening to what you guys stated about my patches check it
>> applies, grammar and build checks. I am still unable to get a good
>> patch and would really appreciate it if someone walks me through
>> one good patch as I will learn this will a tutor and the tutor can
>> help be my router to the community
>
> There are a lot of useful things to do in the Linux kernel community
> besides writing patches.
>
> One of the useful things you could do is simply run linux-next on your
> system, and update whenever new linux-next code comes out. If it breaks
> (which it sometimes does), you can write a bug report, and learn from
> the resulting email thread what caused the problem.
>
> Debugging is a much better way to learn development than developing
> new patches from scratch "just because"...
>
> - --
> All rights reversed.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUGYkCAAoJEM553pKExN6D6ikH/A2iC8wOm1Xa0rpna+i9cCyu
> d3tZof+EbMLezsQjNDXHwJgm7bjsKHT55WT68snliugFueWfkX7c8S48wV2bNso6
> iwObDGCt3iXnuNqWrZ4cjJg4Lk3vOWvs3D1FkCEBlhM8lafJZdaaQfXNVLkOAZyt
> sg9rypTTeV8e1udp/O2UTNP9jwEasLqU3aGXj5AuTUGI77NiquUDn1fwlTwcregr
> nkwv5iCoJuBifm8+GcHHReBzhWX/Ab4d8H+wNGsTHqhlDR3iNyaodMvlHLZcayry
> gkZf3+VcZjR9XClBY5yLeNHmRcYeKFm80XeybF3Ih+zxluB5H2jEOKIp9/MbY88=
> =S6vR
> -END PGP SIGNATURE-
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Sure I will look into linux-next issues later today.
Nick

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Nick Krause]

On Wed, Sep 17, 2014 at 10:39 AM,   wrote:
> On Wed, 17 Sep 2014 08:02:01 -0400, nick said:
>> it off , if not I would like to known exactly where I am wrong so I can 
>> learn.
>
> Somebody wake me up when he actually *means* that.
>
Valdis,
I understand that was what he stated I was looking into how to write a
correct patch not remove needed error messages.
Nick

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Valdis . Kletnieks]

On Wed, 17 Sep 2014 08:02:01 -0400, nick said:
> it off , if not I would like to known exactly where I am wrong so I can learn.

Somebody wake me up when he actually *means* that.



pgpep_zcvBkMR.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Valdis . Kletnieks]

On Wed, 17 Sep 2014 08:09:36 -0400, nick said:

> On 14-09-17 08:05 AM, Greg Freemyer wrote:

> > I don't know that chunk of code, but error messages that go to the kernel
> > log exist for a specific reason.  Taking them out requires a specific 
> > reason.
> >
> > Ie. This would make a good commit message "At this point the condition is
> > well understood and the code that handles it is well tested and has been 
> > stable
> > for 3 years, thus removing the error message."

> This is what I meant with my patch, why have a unneeded error message if the
> code is already tested and only uses
> the return value in that function.

Sorry Nick, but that's *not* what Greg meant.

What he *meant* was that removal of an error message should be its
*own* commit, explaining *why* it was being removed and why it was OK
to do so.

He did *not* say that this particular removal was in fact correct.

He *did* say that such a hypothetical removal *should not* be in a patch
calling itself a checkpatch cleanup.

He *did* say that the patch will require proof that you've examined the
code, understood it, and can explain *why* the patch is OK.


pgpLUVHigG6xc.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Issues with Community

[Rik van Riel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/16/2014 07:22 PM, nick wrote:
> After numerous tries at good patches and still failing , I am
> listening to what you guys stated about my patches check it
> applies, grammar and build checks. I am still unable to get a good
> patch and would really appreciate it if someone walks me through
> one good patch as I will learn this will a tutor and the tutor can
> help be my router to the community

There are a lot of useful things to do in the Linux kernel community
besides writing patches.

One of the useful things you could do is simply run linux-next on your
system, and update whenever new linux-next code comes out. If it breaks
(which it sometimes does), you can write a bug report, and learn from
the resulting email thread what caused the problem.

Debugging is a much better way to learn development than developing
new patches from scratch "just because"...

- -- 
All rights reversed.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUGYkCAAoJEM553pKExN6D6ikH/A2iC8wOm1Xa0rpna+i9cCyu
d3tZof+EbMLezsQjNDXHwJgm7bjsKHT55WT68snliugFueWfkX7c8S48wV2bNso6
iwObDGCt3iXnuNqWrZ4cjJg4Lk3vOWvs3D1FkCEBlhM8lafJZdaaQfXNVLkOAZyt
sg9rypTTeV8e1udp/O2UTNP9jwEasLqU3aGXj5AuTUGI77NiquUDn1fwlTwcregr
nkwv5iCoJuBifm8+GcHHReBzhWX/Ab4d8H+wNGsTHqhlDR3iNyaodMvlHLZcayry
gkZf3+VcZjR9XClBY5yLeNHmRcYeKFm80XeybF3Ih+zxluB5H2jEOKIp9/MbY88=
=S6vR
-END PGP SIGNATURE-

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

some old kernel "cleanup" scripts of mine, still look useful

[Robert P. J. Day]

  once upon a time, as i was diving into the kernel Kbuild
infrastructure, i wrote a number of scripts that would sanity check
the contents of Kconfig files against source files and Makefiles --
not sure if there's a better way to do that these days, but i posted
some of them here if people want to run any of them against their
favourite kernel subsystem:

http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup_scripts

  by "sanity check", i mean that there are a few basic properties of
the kernel build files that should be true, such as:

1) if a Kconfig file defines a config variable, someone else somewhere
   should be checking it

2) if a source file tests an alleged Kconfig variable, some Kconfig
   file should define it

3) if a Makefile conditionally compiles based on a Kconfig variable,
   some Kconfig file should define it

and so on, and so on -- pretty straightforward stuff. and it was
surprising how many irregularities there were (admittedly many of them
minor and causing no problem).

  for example, my script "find_badref_make_configs.sh" would search
either the entire kernel tree or just the directory given by the
optional argument, and identify all Makefiles that tested for
"CONFIG__*" variables that were nowhere defined in the tree. here's
the output from this morning just checking the drivers/ directory:

http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup_scripts#find_badref_make_configs.sh_.28updated_Sep_17.2C_2014.29

there are two typical causes of such things:

* an incomplete *removal* of some feature, or
* an imcomplete *addition* of some feature

for the "ARCH_HIP04" variable listed there, it didn't take long to
stumble on this web page where someone points out that very thing:

http://www.gossamer-threads.com/lists/linux/kernel/2006426

in short, someone added the source and Makefile for that feature, but
hadn't yet added the Kconfig content -- generally frowned upon.

  doing all this once upon a time had a number of benefits for me:

1) forced me to really understand the Kbuild infrastructure
2) improved my shell programming skills
3) let me get some patches into the kernel
4) occasionally, found an actual bug that deserved fixing, for which
   maintainers were grateful

  i have no idea if there's something better these days to do the same
thing -- is there? otherwise, others are free to play with those
scripts and improve them, i'm sure they're not perfect, they used to
generate quite a number of false positives until i reworked them
slightly.

  thoughts?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Greg Freemyer]

On September 17, 2014 8:09:36 AM EDT, nick  wrote:
>
>
>On 14-09-17 08:05 AM, Greg Freemyer wrote:
>> 
>> 
>> On September 17, 2014 7:53:24 AM EDT, nick 
>wrote:
>>>
>>>
>>> On 14-09-17 07:51 AM, Sudip Mukherjee wrote:
 On Wed, Sep 17, 2014 at 5:08 PM, nick  wrote:
>
>
> On 14-09-17 07:20 AM, Robert P. J. Day wrote:
 
>>   anyway, it's time for coffee.
>>
>> rday
>>
> Rday and others,
> That's not what I wanted I was trying to improve my rep after
>>> getting banned from vger.org and now it seems
> I can't even get a patch right. In addition I was trying to do
>check
>>> patch because  it was easier for me
> due to not understanding some parts of the code.
> Nick
>

 try to understand the code first. if you do not understand the code
 how do you know that your patch will not break any part of the
>logic
>>> .
 ok , by adding blank lines you will not break the logic.
 but yesterday in your other patch you removed an error message .
>may
>>> i
 ask why did you think that error message is not required ?

 thanks
 sudip

> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>> I thought that the return statement of NULL to a caller was enough.
>>> Nick 
>> 
>> Uh...
>> 
>> I don't know that chunk of code, but error messages that go to the
>kernel log exist for a specific reason.  Taking them out requires a
>specific reason.
>> 
>> Ie. This would make a good commit message "At this point the
>condition is well understood and the code that handles it is well
>tested and has been stable for 3 years, thus removing the error
>message."
>> 
>> Greg
>> 
>Thanks Greg Again,
>This is what I meant with my patch, why have a unneeded error message
>if the code is already tested and only uses
>the return value in that function.
>Cheers Nick 

Because in general we don't use asserts in the kernel. I'm sure I've used 
10,000s of asserts in user space over the decades.  Zero in the kernel.

Specifically, in user space when writing code we can put asserts throughout the 
code that will cause an immediate code explosion if unexpected things happen.  
In the kernel, the better choice is printing an error message then have the 
code do it's best to handle it.

That still begs the question of why it happened in the first place.  As long as 
the event itself us unexpected (ie. not routine) then the error message should 
remain.  Re-read the sample commit message I wrote.  The first thing I said is 
the "condition is well understood".  Never remove an error message unless you 
can explain with clarity why the "error" is happening.   Obviously in that case 
you should be replacing the error message with a comment that explains the 
condition.

Greg
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[nick]

On 14-09-17 08:17 AM, Kai Bojens wrote:
> On 17-09-14 08:09:36, nick wrote:
> 
> [Again quoting everything]
> 
> Please read and understand this:
> 
> -> http://en.wikipedia.org/wiki/Posting_style#How_much_to_trim
> 
> Your replies are unreadable to me as I don't intend to scroll down
> several pages just to read the one line you added as an answer. If
> you are seriously interested in any help (I for one doubt this…) you
> should start writing in a more readable way.
> 
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
I sent out my last email fine. Your thinking of another email and yes I really 
would like some help as if I learn more I will be able to a good kernel member 
with a tutor or some advice.
Nick 


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Nick Krause]

> Because in general we don't use asserts in the kernel. I'm sure I've used 
> 10,000s of asserts in user space over the decades.  Zero in the kernel.
>
> Specifically, in user space when writing code we can put asserts throughout 
> the code that will cause an immediate code explosion if unexpected things 
> happen.  In the kernel, the better choice is printing an error message then 
> have the code do it's best to handle it.
>
> That still begs the question of why it happened in the first place.  As long 
> as the event itself us unexpected (ie. not routine) then the error message 
> should remain.  Re-read the sample commit message I wrote.  The first thing I 
> said is the "condition is well understood".  Never remove an error message 
> unless you can explain with clarity why the "error" is happening.   Obviously 
> in that case you should be replacing the error message with a comment that 
> explains the condition.
>
> Greg
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Thanks Greg,
I will look into in more carefully later. In addition thanks to all
the others for the patience and help. I understand that
this is not normal in the kernel community and would like to really
thank everyone for the patience and support. I
want to help out and as I am finding out the coding is not the issue
it's my issues with the community which I hope
we can fix in order for me to help the kernel community. In addition I
do find the kernel interesting and really like
working with it, just having issues with understanding how to write patches.
Nick

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Kai Bojens]

On 17-09-14 08:09:36, nick wrote:

[Again quoting everything]

Please read and understand this:

-> http://en.wikipedia.org/wiki/Posting_style#How_much_to_trim

Your replies are unreadable to me as I don't intend to scroll down
several pages just to read the one line you added as an answer. If
you are seriously interested in any help (I for one doubt this…) you
should start writing in a more readable way.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[nick]

On 14-09-17 08:17 AM, Chris Lee wrote:
>>
>> Rday,
>> I meant I didn't understand the code not the effect to write good solid
>> patches and learn it.
>> Please read my messages more carefully.
>> Nick
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
> 
> 
> Terrible reason to submit a patch. If you dont understand the code snippet,
> you should not be submitting patch's against them. You need to fully
> understand the code inside and out before you even consider fixing it.
> 
> Chris
> 
Thanks Chris,
I agree with you now. I didn't mean about check patch for your information but 
on other parts.
Thanks Nick 

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Chris Lee]

>
> Rday,
> I meant I didn't understand the code not the effect to write good solid
> patches and learn it.
> Please read my messages more carefully.
> Nick
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



Terrible reason to submit a patch. If you dont understand the code snippet,
you should not be submitting patch's against them. You need to fully
understand the code inside and out before you even consider fixing it.

Chris
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[nick]

On 14-09-17 08:05 AM, Greg Freemyer wrote:
> 
> 
> On September 17, 2014 7:53:24 AM EDT, nick  wrote:
>>
>>
>> On 14-09-17 07:51 AM, Sudip Mukherjee wrote:
>>> On Wed, Sep 17, 2014 at 5:08 PM, nick  wrote:


 On 14-09-17 07:20 AM, Robert P. J. Day wrote:
>>> 
>   anyway, it's time for coffee.
>
> rday
>
 Rday and others,
 That's not what I wanted I was trying to improve my rep after
>> getting banned from vger.org and now it seems
 I can't even get a patch right. In addition I was trying to do check
>> patch because  it was easier for me
 due to not understanding some parts of the code.
 Nick

>>>
>>> try to understand the code first. if you do not understand the code
>>> how do you know that your patch will not break any part of the logic
>> .
>>> ok , by adding blank lines you will not break the logic.
>>> but yesterday in your other patch you removed an error message . may
>> i
>>> ask why did you think that error message is not required ?
>>>
>>> thanks
>>> sudip
>>>
 ___
 Kernelnewbies mailing list
 Kernelnewbies@kernelnewbies.org
 http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> I thought that the return statement of NULL to a caller was enough.
>> Nick 
> 
> Uh...
> 
> I don't know that chunk of code, but error messages that go to the kernel log 
> exist for a specific reason.  Taking them out requires a specific reason.
> 
> Ie. This would make a good commit message "At this point the condition is 
> well understood and the code that handles it is well tested and has been 
> stable for 3 years, thus removing the error message."
> 
> Greg
> 
Thanks Greg Again,
This is what I meant with my patch, why have a unneeded error message if the 
code is already tested and only uses
the return value in that function.
Cheers Nick 

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[nick]

On 14-09-17 08:00 AM, Robert P. J. Day wrote:
> On Wed, 17 Sep 2014, Greg Freemyer wrote:
> 
>>
>>
>> On September 17, 2014 7:20:42 AM EDT, "Robert P. J. Day" 
>>  wrote:
>> 
>>>
>>>  and, as we've all seen, nick's other flaw is that, quite simply,
>>> he's selfish and greedy. his entire obsession is with the output of
>>> checkpatch, which means he wants to grab all the trivial cleanup (the
>>> low-hanging fruit, as it were) for himself, and not leave any for
>>> others. rather than take the time to understand the code, nick wants
>>> checkpatch to do all the work for him. in the end, nick doesn't want
>>> to do any work or understand how the kernel actually works -- he just
>>> wants patches, and he wants them as quickly and cheaply as possible.
>>
>> Nick and his patches may have plenty of flaws, but I think it is a
>> bit crazy to call his effort to get his first patch into the kernel
>> greedy.
> 
>   i was actually referring to nick's more recent posting where he
> vowed to use his patch as the template to start cleaning up all of
> drivers/staging/. i thought i was fairly clear that there is nothing
> wrong with *starting* with stylistic cleanup, but nick made it quite
> clear he planned on doing this all over drivers/staging. *that* is
> what i was referring to.
> 
> rday
> 
Rday,
Your reading that wrong what I mean is to use the format as a template for 
patches I am going to send out,
not clean up drivers/staging all of it a least. I was stating I wanted to only 
clean up a bit there in order
to get comfortable with sending out patches. 
Sorry about the miswritten message,
Nick  

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Greg Freemyer]

On September 17, 2014 7:53:24 AM EDT, nick  wrote:
>
>
>On 14-09-17 07:51 AM, Sudip Mukherjee wrote:
>> On Wed, Sep 17, 2014 at 5:08 PM, nick  wrote:
>>>
>>>
>>> On 14-09-17 07:20 AM, Robert P. J. Day wrote:
>> 
   anyway, it's time for coffee.

 rday

>>> Rday and others,
>>> That's not what I wanted I was trying to improve my rep after
>getting banned from vger.org and now it seems
>>> I can't even get a patch right. In addition I was trying to do check
>patch because  it was easier for me
>>> due to not understanding some parts of the code.
>>> Nick
>>>
>> 
>> try to understand the code first. if you do not understand the code
>> how do you know that your patch will not break any part of the logic
>.
>> ok , by adding blank lines you will not break the logic.
>> but yesterday in your other patch you removed an error message . may
>i
>> ask why did you think that error message is not required ?
>> 
>> thanks
>> sudip
>> 
>>> ___
>>> Kernelnewbies mailing list
>>> Kernelnewbies@kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>I thought that the return statement of NULL to a caller was enough.
>Nick 

Uh...

I don't know that chunk of code, but error messages that go to the kernel log 
exist for a specific reason.  Taking them out requires a specific reason.

Ie. This would make a good commit message "At this point the condition is well 
understood and the code that handles it is well tested and has been stable for 
3 years, thus removing the error message."

Greg

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[nick]

On 14-09-17 07:56 AM, Greg Freemyer wrote:
> 
> 
> On September 17, 2014 7:20:42 AM EDT, "Robert P. J. Day" 
>  wrote:
> 
>>
>>  and, as we've all seen, nick's other flaw is that, quite simply,
>> he's selfish and greedy. his entire obsession is with the output of
>> checkpatch, which means he wants to grab all the trivial cleanup (the
>> low-hanging fruit, as it were) for himself, and not leave any for
>> others. rather than take the time to understand the code, nick wants
>> checkpatch to do all the work for him. in the end, nick doesn't want
>> to do any work or understand how the kernel actually works -- he just
>> wants patches, and he wants them as quickly and cheaply as possible.
> 
> Nick and his patches may have plenty of flaws, but I think it is a bit crazy 
> to call his effort to get his first patch into the kernel greedy.
> 
>>From what little I know he originally started trying to make functional code 
>>changes around various fixme's in the code.  Not surprisingly, that took more 
>>overall kernel knowledge than he had.  If fixme's were trivial, they would 
>>have been fixed in the first place, not a comment.
> 
> If Greg KH welcomes code style patches in the staging code as a way for 
> newbies to learn the workflow, then that is a great thing.
> 
> Greg (not kh)
> 
Thanks Greg,
That is exactly what happened with my issues, I started on things with more 
then I could handle and due to that and not listening was banned. If someone 
with re look at  my patch and tell if it's OK or not, if it's good please sent
it off , if not I would like to known exactly where I am wrong so I can learn.
Nick 

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Robert P. J. Day]

On Wed, 17 Sep 2014, Greg Freemyer wrote:

>
>
> On September 17, 2014 7:20:42 AM EDT, "Robert P. J. Day" 
>  wrote:
> 
> >
> >  and, as we've all seen, nick's other flaw is that, quite simply,
> >he's selfish and greedy. his entire obsession is with the output of
> >checkpatch, which means he wants to grab all the trivial cleanup (the
> >low-hanging fruit, as it were) for himself, and not leave any for
> >others. rather than take the time to understand the code, nick wants
> >checkpatch to do all the work for him. in the end, nick doesn't want
> >to do any work or understand how the kernel actually works -- he just
> >wants patches, and he wants them as quickly and cheaply as possible.
>
> Nick and his patches may have plenty of flaws, but I think it is a
> bit crazy to call his effort to get his first patch into the kernel
> greedy.

  i was actually referring to nick's more recent posting where he
vowed to use his patch as the template to start cleaning up all of
drivers/staging/. i thought i was fairly clear that there is nothing
wrong with *starting* with stylistic cleanup, but nick made it quite
clear he planned on doing this all over drivers/staging. *that* is
what i was referring to.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Greg Freemyer]

On September 17, 2014 7:20:42 AM EDT, "Robert P. J. Day" 
 wrote:

>
>  and, as we've all seen, nick's other flaw is that, quite simply,
>he's selfish and greedy. his entire obsession is with the output of
>checkpatch, which means he wants to grab all the trivial cleanup (the
>low-hanging fruit, as it were) for himself, and not leave any for
>others. rather than take the time to understand the code, nick wants
>checkpatch to do all the work for him. in the end, nick doesn't want
>to do any work or understand how the kernel actually works -- he just
>wants patches, and he wants them as quickly and cheaply as possible.

Nick and his patches may have plenty of flaws, but I think it is a bit crazy to 
call his effort to get his first patch into the kernel greedy.

>From what little I know he originally started trying to make functional code 
>changes around various fixme's in the code.  Not surprisingly, that took more 
>overall kernel knowledge than he had.  If fixme's were trivial, they would 
>have been fixed in the first place, not a comment.

If Greg KH welcomes code style patches in the staging code as a way for newbies 
to learn the workflow, then that is a great thing.

Greg (not kh)
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[nick]

On 14-09-17 07:53 AM, Robert P. J. Day wrote:
> 
>   what did i say? what did i just say? i wrote:
> 
> On Wed, 17 Sep 2014, nick wrote:
>> On 14-09-17 07:20 AM, Robert P. J. Day wrote:
>>>
>>>   and, as we've all seen, nick's other flaw is that, quite simply,
>>> he's selfish and greedy. his entire obsession is with the output
>>> of checkpatch, which means he wants to grab all the trivial
>>> cleanup (the low-hanging fruit, as it were) for himself, and not
>>> leave any for others. rather than take the time to understand the
>   ^^^
>>> code, nick wants checkpatch to do all the work for him. in the
>>> end, nick doesn't want to do any work or understand how the kernel
>>> actually works -- he just wants patches, and he wants them as
>>> quickly and cheaply as possible.
> 
>   to which nick responds (unbelievably, and confirming what i had
> just written):
> 
>> That's not what I wanted I was trying to improve my rep after
>> getting banned from vger.org and now it seems I can't even get a
>> patch right. In addition I was trying to do check patch because it
>> was easier for me due to not understanding some parts of the code.
>   ^
> 
>   i rarely have my speculation confirmed so rapidly and completely.
> 
> rday
> 
Rday,
I meant I didn't understand the code not the effect to write good solid patches 
and learn it.
Please read my messages more carefully.
Nick

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Robert P. J. Day]

  what did i say? what did i just say? i wrote:

On Wed, 17 Sep 2014, nick wrote:
> On 14-09-17 07:20 AM, Robert P. J. Day wrote:
> >
> >   and, as we've all seen, nick's other flaw is that, quite simply,
> > he's selfish and greedy. his entire obsession is with the output
> > of checkpatch, which means he wants to grab all the trivial
> > cleanup (the low-hanging fruit, as it were) for himself, and not
> > leave any for others. rather than take the time to understand the
  ^^^
> > code, nick wants checkpatch to do all the work for him. in the
> > end, nick doesn't want to do any work or understand how the kernel
> > actually works -- he just wants patches, and he wants them as
> > quickly and cheaply as possible.

  to which nick responds (unbelievably, and confirming what i had
just written):

> That's not what I wanted I was trying to improve my rep after
> getting banned from vger.org and now it seems I can't even get a
> patch right. In addition I was trying to do check patch because it
> was easier for me due to not understanding some parts of the code.
  ^

  i rarely have my speculation confirmed so rapidly and completely.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday




___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[nick]

On 14-09-17 07:51 AM, Sudip Mukherjee wrote:
> On Wed, Sep 17, 2014 at 5:08 PM, nick  wrote:
>>
>>
>> On 14-09-17 07:20 AM, Robert P. J. Day wrote:
> 
>>>   anyway, it's time for coffee.
>>>
>>> rday
>>>
>> Rday and others,
>> That's not what I wanted I was trying to improve my rep after getting banned 
>> from vger.org and now it seems
>> I can't even get a patch right. In addition I was trying to do check patch 
>> because  it was easier for me
>> due to not understanding some parts of the code.
>> Nick
>>
> 
> try to understand the code first. if you do not understand the code
> how do you know that your patch will not break any part of the logic .
> ok , by adding blank lines you will not break the logic.
> but yesterday in your other patch you removed an error message . may i
> ask why did you think that error message is not required ?
> 
> thanks
> sudip
> 
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
I thought that the return statement of NULL to a caller was enough.
Nick 

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Sudip Mukherjee]

On Wed, Sep 17, 2014 at 5:08 PM, nick  wrote:
>
>
> On 14-09-17 07:20 AM, Robert P. J. Day wrote:

>>   anyway, it's time for coffee.
>>
>> rday
>>
> Rday and others,
> That's not what I wanted I was trying to improve my rep after getting banned 
> from vger.org and now it seems
> I can't even get a patch right. In addition I was trying to do check patch 
> because  it was easier for me
> due to not understanding some parts of the code.
> Nick
>

try to understand the code first. if you do not understand the code
how do you know that your patch will not break any part of the logic .
ok , by adding blank lines you will not break the logic.
but yesterday in your other patch you removed an error message . may i
ask why did you think that error message is not required ?

thanks
sudip

> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[nick]

On 14-09-17 07:20 AM, Robert P. J. Day wrote:
> On Tue, 16 Sep 2014, Greg KH wrote:
> 
>> On Tue, Sep 16, 2014 at 11:42:18PM -0400, valdis.kletni...@vt.edu wrote:
>>> (And this sort of analysis is exactly *why* people need to apply their 
>>> brains
>>> when looking at checkpatch output)
>>
>> No one has ever said that they shouldn't.
>>
>> Remember, I know _lots_ of kernel developers who started with just
>> "checkpatch cleanups on staging drivers" and they moved on to much
>> "higher" roles in the kernel developer ecosystem (jobs, maintainers
>> of subsystems, keynote talks at conferences, etc.)
>>
>> Don't "po po" it as something that shouldn't be a valid place to
>> start, it is, and is why I do the work to review all of the many
>> thousands of staging patches every release cycle.
>>
>> No one is forcing you to write those patches, or read / review them,
>> so don't discourage others to provide them either please.  I most
>> certainly do not.
> 
>   so while i'm waxing philosophical, some other thoughts that occurred
> to me that reflect on how i got started, and ways to become a more and
> more useful contributor to the kernel for newbies (and i'm willing to
> be corrected on any of this).
> 
>   first, stop with the blind running of checkpatch unless you're
> willing to take the results and examine the *context* in which they
> occur. that file needs blank lines? ok, does it reside in a directory
> of related files that could *also* use some blank lines? then do them
> *all* -- don't waste peoples' time fixing one file at a time. if you
> can do the same stylistic cleanup on an entire subsystem, go for it,
> and don't clutter up the git log with numerous trivial commits.
> 
>   *but* ... don't try to sneak functional changes in there at the same
> time. if it's a style cleanup, then it's a *style* cleanup. one thing
> at a time. but there are other places you can make a name.
> 
>   first, read the Documentation/ directory -- there's lots of content
> there, and quite a bit of it is out of date or just plain obsolete.
> and if you want people to love you, improve the documentation. but,
> see, that's going to take some work. and that's because it requires
> you to read the documentation, then go off and examine the
> corresponding code to see if it still matches. and why is this good?
> 
>   because while updating the Documentation/ content is safe and can't
> break anything, the side effect is that you *learn* about that
> particular subsystem, you get some nifty patches into the kernel, and
> you make lots and lots of friends.
> 
>   another place to get cheap patches is to repair any kernel-doc
> warnings, and there are *always* plenty of those. again, fixing
> kernel-doc content shouldn't break anything, it should be easy
> patching, and it normally requires you to at least examine the code to
> make sure you're fixing it properly. so, you get patches into the
> kernel, and you learn a bit more about some code. win-win.
> 
>   last point here regarding something gregkh wrote -- yes, it's fine
> to *start* with simple stylistic cleanup, especially if checkpatch
> does all the work for you. but remember, that's low-hanging fruit, and
> you shouldn't be greedy and try and do all of it. if stylistic cleanup
> is a way for beginners to get their first patches into the kernel,
> then don't be a pig and try to do it all -- leave some for others to
> cut their teeth on. and what is the point of all this?
> 
>   quite simply, this is also why nick krause will never be a useful
> member of the kernel community. i suggested a while back that nick
> could start with improving the documentation, for all the reasons i
> mentioned above. his response was that he didn't know enough to do
> that, which is an astonishing thing to admit. if you don't know enough
> to improve the basic documentation, you have no right to be mucking
> around in the code.
> 
>   and, as we've all seen, nick's other flaw is that, quite simply,
> he's selfish and greedy. his entire obsession is with the output of
> checkpatch, which means he wants to grab all the trivial cleanup (the
> low-hanging fruit, as it were) for himself, and not leave any for
> others. rather than take the time to understand the code, nick wants
> checkpatch to do all the work for him. in the end, nick doesn't want
> to do any work or understand how the kernel actually works -- he just
> wants patches, and he wants them as quickly and cheaply as possible.
> 
>   anyway, it's time for coffee.
> 
> rday
> 
Rday and others,
That's not what I wanted I was trying to improve my rep after getting banned 
from vger.org and now it seems
I can't even get a patch right. In addition I was trying to do check patch 
because  it was easier for me
due to not understanding some parts of the code.
Nick 

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Robert P. J. Day]

On Tue, 16 Sep 2014, Greg KH wrote:

> On Tue, Sep 16, 2014 at 11:42:18PM -0400, valdis.kletni...@vt.edu wrote:
> > (And this sort of analysis is exactly *why* people need to apply their 
> > brains
> > when looking at checkpatch output)
>
> No one has ever said that they shouldn't.
>
> Remember, I know _lots_ of kernel developers who started with just
> "checkpatch cleanups on staging drivers" and they moved on to much
> "higher" roles in the kernel developer ecosystem (jobs, maintainers
> of subsystems, keynote talks at conferences, etc.)
>
> Don't "po po" it as something that shouldn't be a valid place to
> start, it is, and is why I do the work to review all of the many
> thousands of staging patches every release cycle.
>
> No one is forcing you to write those patches, or read / review them,
> so don't discourage others to provide them either please.  I most
> certainly do not.

  so while i'm waxing philosophical, some other thoughts that occurred
to me that reflect on how i got started, and ways to become a more and
more useful contributor to the kernel for newbies (and i'm willing to
be corrected on any of this).

  first, stop with the blind running of checkpatch unless you're
willing to take the results and examine the *context* in which they
occur. that file needs blank lines? ok, does it reside in a directory
of related files that could *also* use some blank lines? then do them
*all* -- don't waste peoples' time fixing one file at a time. if you
can do the same stylistic cleanup on an entire subsystem, go for it,
and don't clutter up the git log with numerous trivial commits.

  *but* ... don't try to sneak functional changes in there at the same
time. if it's a style cleanup, then it's a *style* cleanup. one thing
at a time. but there are other places you can make a name.

  first, read the Documentation/ directory -- there's lots of content
there, and quite a bit of it is out of date or just plain obsolete.
and if you want people to love you, improve the documentation. but,
see, that's going to take some work. and that's because it requires
you to read the documentation, then go off and examine the
corresponding code to see if it still matches. and why is this good?

  because while updating the Documentation/ content is safe and can't
break anything, the side effect is that you *learn* about that
particular subsystem, you get some nifty patches into the kernel, and
you make lots and lots of friends.

  another place to get cheap patches is to repair any kernel-doc
warnings, and there are *always* plenty of those. again, fixing
kernel-doc content shouldn't break anything, it should be easy
patching, and it normally requires you to at least examine the code to
make sure you're fixing it properly. so, you get patches into the
kernel, and you learn a bit more about some code. win-win.

  last point here regarding something gregkh wrote -- yes, it's fine
to *start* with simple stylistic cleanup, especially if checkpatch
does all the work for you. but remember, that's low-hanging fruit, and
you shouldn't be greedy and try and do all of it. if stylistic cleanup
is a way for beginners to get their first patches into the kernel,
then don't be a pig and try to do it all -- leave some for others to
cut their teeth on. and what is the point of all this?

  quite simply, this is also why nick krause will never be a useful
member of the kernel community. i suggested a while back that nick
could start with improving the documentation, for all the reasons i
mentioned above. his response was that he didn't know enough to do
that, which is an astonishing thing to admit. if you don't know enough
to improve the basic documentation, you have no right to be mucking
around in the code.

  and, as we've all seen, nick's other flaw is that, quite simply,
he's selfish and greedy. his entire obsession is with the output of
checkpatch, which means he wants to grab all the trivial cleanup (the
low-hanging fruit, as it were) for himself, and not leave any for
others. rather than take the time to understand the code, nick wants
checkpatch to do all the work for him. in the end, nick doesn't want
to do any work or understand how the kernel actually works -- he just
wants patches, and he wants them as quickly and cheaply as possible.

  anyway, it's time for coffee.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday





___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Issues with Community

[Jake Campbell]

Nick,

Why do you persist on trying to get a patch into the kernel, despite your
continuous failed efforts after help has been given to improve them?

To be completely honest, and I do not mean to offend, but being a Kernel
Newbie myself on this list for only the past few months, already you have
proven yourself to be an example of what _not_ to do to be a helpful member
of the community... Even to the extent of individual threads created to
address this nuisance.

At this point, most people would immediately realize negative effects of
their actions, both to themselves and everyone else, and work to improve
them before even attempting to reconcile their past actions.

Why have you not sought help elsewhere?  You must realize that you are in
no way helping yourself by acting this way.

On Sep 16, 2014 5:23 PM, "nick"  wrote:

> After numerous tries at good patches and still failing , I am listening to
> what you guys stated
> about my patches check it applies, grammar and build checks. I am still
> unable to get a good patch
> and would really appreciate it if someone walks me through one good patch
> as I will learn this will
> a tutor and the tutor can help be my router to the community for now in
> order to start helping me learn
> how to be involved correctly and follow the community rules. I am willing
> to work on my patches if someone
> is willing to do this for me and help me improve my taste in the
> communities mouth.
> Thanks,
> Nick
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: A quick guide to why stand-alone checkpatch patches suck...

[Robert P. J. Day]

On Tue, 16 Sep 2014, Greg KH wrote:

> On Tue, Sep 16, 2014 at 11:42:18PM -0400, valdis.kletni...@vt.edu wrote:
> > (And this sort of analysis is exactly *why* people need to apply their 
> > brains
> > when looking at checkpatch output)
>
> No one has ever said that they shouldn't.
>
> Remember, I know _lots_ of kernel developers who started with just
> "checkpatch cleanups on staging drivers" and they moved on to much
> "higher" roles in the kernel developer ecosystem (jobs, maintainers
> of subsystems, keynote talks at conferences, etc.)
>
> Don't "po po" it as something that shouldn't be a valid place to
> start, it is, and is why I do the work to review all of the many
> thousands of staging patches every release cycle.
>
> No one is forcing you to write those patches, or read / review them,
> so don't discourage others to provide them either please.  I most
> certainly do not.

  as someone who started out this way (submitting "trivial" patches,
and still do from time to time) and who now makes a living teaching
kernel programming and embedded linux and device drivers, perhaps i
can add some perspective, and also explain why nick krause is
monstrously off-base in everything he touches.

  of *course* it's useful that beginners get the opportunity to submit
trivial patches based on nothing but perhaps checkpatch warnings --
it's a great way to get your feet wet, burn in the lessons of how to
write and submit a proper patch, and so on and so on.  but notice the
really important point gregkh makes here:

> Remember, I know _lots_ of kernel developers who started with just
> "checkpatch cleanups on staging drivers" and they moved on to much
> "higher" roles in the kernel developer ecosystem (jobs, maintainers
> of subsystems, keynote talks at conferences, etc.)

the obvious implication is that, while you *start* simple, the goal is
to ***move up***. trivial, style-based patches are a great
*introduction*, but everyone should have the eventual goal of more and
more sophisticated patches and contributions involving tweaking code
and eventually writing new subsystems, etc, etc. and this is where
nick krause is failing miserably.

  nick shows absolutely no interest in understanding the code he's
looking at. his approach to patches is to blindly run checkpatch, look
at the first warning, go to that file, and try to "fix" it, without in
any way whatsoever trying to understand the code in a larger context.
if checkpatch says to add blank lines, nick will add blank lines,
after which he will understand no more about the code than when he
started, which is why, regardless of how long nick does this, he will
never, ever, ever understand any more about the kernel than he does
now.

  nick has made it obvious he has no interest in actually
understanding how the kernel works -- all he is obsessed with is
getting his name into the git log as the author of a patch; hence, his
relentless labour in submitting variation after variation of a patch
that does nothing more than add three blank lines to a single file.

  nick has long since lost sight of what that single source file is
doing (if he ever even cared what it did in the first place). he is
now in a very unhealthy place where he is going to get those blank
lines in there if it kills him or pisses off every single person on
the kernelnewbies mailing list, and that is precisely why working with
him is a complete waste of time.

  other beginners will start where nick is now and, in short order,
they will progress to bigger and better things -- as greg kh suggests,
writing code, becoming subsystem maintainers, giving keynotes. nick
will never, ever, ever do any of this; five years from now, nick will
still blindly be running checkpatch, then going to files looking for
blank lines to add. he will never progress beyond that, simply because
he's doing this for all the wrong reasons.

  nick doesn't care about how the kernel works. nick just wants to get
a patch in there somewhere ... anywhere, it doesn't matter. which is
why he is not worth anyone's time. nick will never be a useful
contributor to the kernel community because, in the end, he doesn't
really care about the kernel.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Issues with Community

[Anuz Pratap Singh Tomar]

ahahaha, this is a total win.

"There are many other theories such as it could be some joruno or redditter
trying to get burned by Linus to get some headlines. It could be NSA trying
to sneak their code, it could be Russians. But none of these theories beat
the one by Giorgio A. Tsoukalos who believes that it’s aliens trolling the
Linux Kernel mailing list."

On Wed, Sep 17, 2014 at 11:14 AM, Jesus Bustos 
wrote:

> Nick,
>
> What do you think about the following :
>
>
> http://www.themukt.com/2014/08/04/someone-trolling-linux-kernel-mailing-lists-really-hard/
>
> Regards.
>
> On 17 September 2014 11:00, Hugo Mills  wrote:
>
>> On Tue, Sep 16, 2014 at 07:22:15PM -0400, nick wrote:
>> > After numerous tries at good patches and still failing , I am
>> > listening to what you guys stated about my patches check it applies,
>> > grammar and build checks. I am still unable to get a good patch and
>> > would really appreciate it if someone walks me through one good
>> > patch as I will learn this will a tutor and the tutor can help be my
>> > router to the community for now in order to start helping me learn
>> > how to be involved correctly and follow the community rules. I am
>> > willing to work on my patches if someone is willing to do this for
>> > me and help me improve my taste in the communities mouth.
>>
>>Pretty much everybody who's written you an email from these mailing
>> lists in the last two months has been trying to help you in this way.
>> You've consistently ignored (or at least not followed) the advice,
>> which makes the people who gave it feel like it's not worth the
>> effort. Therefore, as it stands, anyone considering helping you will
>> probably think it's a complete waste of time.
>>
>>Phrases such as you've used to date: "I must check things more
>> carefully", "I'm willing to work on my patches", "I will learn this"
>> are no longer good enough: You've used wording like this before, and
>> failed to show that you've learned anything as a result.
>>
>>So, unless you can explain in detail *why* you ignored all the
>> previous advice, *and* you can explain in detail *how* you are modifying
>> your behaviour and working practices so that you can learn from future
>> advice, nobody is likely to want to help you.
>>
>>Go back and read my mail from yesterday. Engage with it -- write
>> your thoughts and explanations on a point-by-point basis. A single
>> three-line response at the end of the mail is not sufficient. If you
>> can't engage with that mail in detail, follow the advice I gave and
>> seek formal assistance for your learning difficulties.
>>
>>Hugo.
>>
>> --
>> === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
>>   PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
>>--- There are three mistaikes in this sentance. ---
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>


-- 
Thank you
Warm Regards
Anuz
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Issues with Community

[Jesus Bustos]

Nick,

What do you think about the following :

http://www.themukt.com/2014/08/04/someone-trolling-linux-kernel-mailing-lists-really-hard/

Regards.

On 17 September 2014 11:00, Hugo Mills  wrote:

> On Tue, Sep 16, 2014 at 07:22:15PM -0400, nick wrote:
> > After numerous tries at good patches and still failing , I am
> > listening to what you guys stated about my patches check it applies,
> > grammar and build checks. I am still unable to get a good patch and
> > would really appreciate it if someone walks me through one good
> > patch as I will learn this will a tutor and the tutor can help be my
> > router to the community for now in order to start helping me learn
> > how to be involved correctly and follow the community rules. I am
> > willing to work on my patches if someone is willing to do this for
> > me and help me improve my taste in the communities mouth.
>
>Pretty much everybody who's written you an email from these mailing
> lists in the last two months has been trying to help you in this way.
> You've consistently ignored (or at least not followed) the advice,
> which makes the people who gave it feel like it's not worth the
> effort. Therefore, as it stands, anyone considering helping you will
> probably think it's a complete waste of time.
>
>Phrases such as you've used to date: "I must check things more
> carefully", "I'm willing to work on my patches", "I will learn this"
> are no longer good enough: You've used wording like this before, and
> failed to show that you've learned anything as a result.
>
>So, unless you can explain in detail *why* you ignored all the
> previous advice, *and* you can explain in detail *how* you are modifying
> your behaviour and working practices so that you can learn from future
> advice, nobody is likely to want to help you.
>
>Go back and read my mail from yesterday. Engage with it -- write
> your thoughts and explanations on a point-by-point basis. A single
> three-line response at the end of the mail is not sufficient. If you
> can't engage with that mail in detail, follow the advice I gave and
> seek formal assistance for your learning difficulties.
>
>Hugo.
>
> --
> === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
>   PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
>--- There are three mistaikes in this sentance. ---
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [PATCH] staging wlan-ng: Add missing blank lines after declarations

[Robert P. J. Day]

On Tue, 16 Sep 2014, Nicholas Krause wrote:

> Fixing trivial checkpatch warnings about missing blank lines after 
> declarations.
>
> Signed-off-by: Nicholas Krause 

   ... snip ...

>From Documentation/SubmittingPatches:

  "The "summary phrase" may be prefixed by tags enclosed in square
brackets: "Subject: [PATCH tag] ".  The tags are not
considered part of the summary phrase, but describe how the patch
should be treated.  Common tags might include a version descriptor if
the multiple versions of the patch have been sent out in response to
comments (i.e., "v1, v2, v3") ..."

  this is now ... what? version 6? 7? 8? of a patch that adds three
blank lines to a file. so ... still wrong.

  didn't you say you were going to leave if you couldn't submit the
next patch properly? whatever happened to that promise?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Issues with Community

[Hugo Mills]

On Tue, Sep 16, 2014 at 07:22:15PM -0400, nick wrote:
> After numerous tries at good patches and still failing , I am
> listening to what you guys stated about my patches check it applies,
> grammar and build checks. I am still unable to get a good patch and
> would really appreciate it if someone walks me through one good
> patch as I will learn this will a tutor and the tutor can help be my
> router to the community for now in order to start helping me learn
> how to be involved correctly and follow the community rules. I am
> willing to work on my patches if someone is willing to do this for
> me and help me improve my taste in the communities mouth.

   Pretty much everybody who's written you an email from these mailing
lists in the last two months has been trying to help you in this way.
You've consistently ignored (or at least not followed) the advice,
which makes the people who gave it feel like it's not worth the
effort. Therefore, as it stands, anyone considering helping you will
probably think it's a complete waste of time.

   Phrases such as you've used to date: "I must check things more
carefully", "I'm willing to work on my patches", "I will learn this"
are no longer good enough: You've used wording like this before, and
failed to show that you've learned anything as a result.

   So, unless you can explain in detail *why* you ignored all the
previous advice, *and* you can explain in detail *how* you are modifying
your behaviour and working practices so that you can learn from future
advice, nobody is likely to want to help you.

   Go back and read my mail from yesterday. Engage with it -- write
your thoughts and explanations on a point-by-point basis. A single
three-line response at the end of the mail is not sufficient. If you
can't engage with that mail in detail, follow the advice I gave and
seek formal assistance for your learning difficulties.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- There are three mistaikes in this sentance. ---   


signature.asc
Description: Digital signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies