regarding const variables/structures

[inventsekar@gmail.com (inventsekar)]

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>