kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: der.herr@hofr.at (Nicholas Mc Guire)
To: kernelnewbies@lists.kernelnewbies.org
Subject: regarding const variables/structures
Date: Wed, 12 Sep 2018 07:08:38 +0000	[thread overview]
Message-ID: <20180912070838.GA7684@osadl.at> (raw)
In-Reply-To: <CAJd9=00U1MAb=Pb0UqNKWEhGL8z9gYnNgG7y=A3xH4cSN-dH9w@mail.gmail.com>

On Wed, Sep 12, 2018 at 11:50:35AM +0530, inventsekar wrote:
> Hi All...
> One curious question..
> 
> Linux Foundation tweeted this -
> Meet Bhumika Goyal, age 22, from India. She has had more 340 patches
> accepted into the Linux kernel, which helped her land one of our two Linux
> Kernel Guru LiFT scholarships:
> https://twitter.com/linuxfoundation/status/940340927897489408?lang=en
> 
> and her commits are -
> https://github.com/torvalds/linux/commits?author=bhumikagoyal
> 
> One of my friend told me that, most/many of patches are just converting
> variables to "*constant*"
> 
> For example - platform/chrome: chromeos_laptop: make chromeos_laptop const
> -
> 
> Declare chromeos_laptop structures as *const *as they are only used during
> a copy operation. As their value is never modified during runtime, they
> can be made const.
> 
> 
> the question is that, how these many const variable issues are left/missed
> by the previous developers?!?! per my little knowledge, this task looks
> like a simple one.. many other Kernel Developers should have thought and
> made these changes long before, but i am not able to understand why this
> wasnt done until recently?!?!?
>
well (almost) all issues are simple once they are known, and in 16M LoC or
what ever the kernel currently is, it is not a big surprise to find a few
hundred issues of almost any bug-class. If you really want to know how bad
the problem is, or rather how much it says about the overall quality, you
would need to answer at least two questions.
 1) how many cases of const are missing
 2) how many cases of const are in use correctly
just counting how many are missing does not tell you much about how good or
bad kernel developers are. If 99% of the cases are handled correctly I would
say thats good - but given the size of the kernel that would probably mean
that there still are quite a few that are not handled correctly. Further you
would probably need to check how old the code was that that was fixed up.

A brute force grep in the kernel shows that there are 130493 " const " in 
ther (as of 4.18.2 in -stable) so if the developers got 340 wrong - I would
say thats not that scary after all the consequence of not having the const in
there are quite benign.

I think that it is often times not a mater of not seeing issues but it is a
matter of priority and available time - and what this case really does show
is that there are opportunities for people moving into kernel development
to get to work on simple problems to start with where they can get well
acquainted with the procedural issues first - I think that is a good
thing and may actually be important to allow new developers to join in.


thx!
hofrat 

  parent reply	other threads:[~2018-09-12  7:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12  6:20 regarding const variables/structures inventsekar
2018-09-12  6:51 ` Greg KH
2018-09-12  7:08 ` Nicholas Mc Guire [this message]
2018-09-12 17:10   ` inventsekar
2018-09-12 17:53     ` valdis.kletnieks at vt.edu
2018-09-12 18:23       ` inventsekar
2018-09-13  9:50         ` Tobin C. Harding
2018-09-14 19:49           ` inventsekar
2018-09-17  7:29             ` Shakthi Kannan
2018-09-18  5:46               ` inventsekar
2018-09-17 15:00             ` valdis.kletnieks at vt.edu
2018-09-13  3:42   ` inventsekar
2018-09-13  6:07     ` Nicholas Mc Guire
2018-09-14 19:52       ` inventsekar
2018-09-14 22:09         ` Kenneth Adam Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180912070838.GA7684@osadl.at \
    --to=der.herr@hofr.at \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).