kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: inventsekar@gmail.com (inventsekar)
To: kernelnewbies@lists.kernelnewbies.org
Subject: regarding const variables/structures
Date: Wed, 12 Sep 2018 22:40:50 +0530	[thread overview]
Message-ID: <CAJd9=02nmH5QpMEuHWr_3n16cnEEKD_DtKjqmuAAa7tdA6QkRA@mail.gmail.com> (raw)
In-Reply-To: <20180912070838.GA7684@osadl.at>

Thx Hofrat and Greg..
Kindly suggest me one more thing...(for newbies like me)...
I hope she didn't complete that job
(Converting all structs/variables to const)
(As she did that in last Dec, some new code may be written in the old
style, ...Or, she may not have converted 100% structs, variables)

So, please suggest some subsystems or some small puedes of code, where i
can "dwell" sometimes and submit my first patch.

Best regards,
Sekar



On Wed 12 Sep, 2018, 12:38 PM Nicholas Mc Guire, <der.herr@hofr.at> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180912/c5729f90/attachment.html>

  reply	other threads:[~2018-09-12 17:10 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
2018-09-12 17:10   ` inventsekar [this message]
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='CAJd9=02nmH5QpMEuHWr_3n16cnEEKD_DtKjqmuAAa7tdA6QkRA@mail.gmail.com' \
    --to=inventsekar@gmail.com \
    --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).