regarding const variables/structures

[Kenneth Adam Miller]

Don't be discouraged!

So, if you only read the code, it may appear to you that "in the small" you
are understanding the code. But, the possible states and paths are a large
combinatorial, and lots of things can happen at runtime that you will not
be able to predict, even after only reading the code once.

Therefore, the best thing to do is to set up some testing framework - that
would be highly useful. There isn't much testing capability for the linux
kernel itself, other than to have a dedicated machine (be it hardware or
qemu or other emulator). The only way to know if something works is to try
it, but when it comes to the linux kernel, it cannot be run except with the
special conditions that exist at the kernel level, which itself is a
problem.

I'm not sure if such as I am suggesting is really so feasible or realistic
(it certainly isn't possible for some portions of the kernel), but if you
could cut off any particular module that resides within the innards of the
kernel, and make it retargetably compilable so that you can produce
userland modules with it, that would make for a highly ambitious project
that would allow kernel developers to more quickly iterate and test their
work as they are changing things. You would have to provide, for the set of
interfaces that such an inner kernel module were to consume, a second
implementation, so that the same header can be reused and the service
guarantees maintained. There are lots of things to choose from within the
kernel land.

For example, there are many data structures that the kernel development
environment provides. You could pick one and create a series of sanity
checks, and some harness to run each of them safely to establish for
yourself testably what the properties are that such a structure or service
provides. Then, you could expose to others your tests which they could
consume and use to both help debug their code and to maintain it, and if
you did the faking of the implementation right so that you can compile it
for different targets, users would be able to have a subset of their code
produce both kernel and userland targets, where the userland targets have
some best effort one to one implementation (if not the real thing excised
from the kernel) to establish their correct operation.

It sounds like it isn't much if you think that the only thing to test is
lists. However, there's nothing stopping you from at least trying to do
this for whole portions of the kernel. It may comprise a lot of work, but
if you have a userland dummy that mocks out the behavior of something like
a scheduler or userland page alignment algorithm so that it can be
decoupled and safely run in some simulation capability, you will have made
a lot of developers much more productive.

On Fri, Sep 14, 2018 at 12:53 PM inventsekar <inventsekar at gmail.com> wrote:

> Hi, for the past three years I have been trying hard to do Linux kernel
> development, but, with No success.
>
> I don't know what is the exact reason...maybe, I didn't do much
> practical, all the times I was only reading reading reading... so you can
> understand my frustration, that I wanted to submit my first patch
> asap...and then slowly I can do concentrate on other areas of kernel
> development... ok thank you.
>
> On Thu 13 Sep, 2018, 11:37 AM Nicholas Mc Guire, <der.herr at hofr.at> wrote:
>
>> On Thu, Sep 13, 2018 at 09:12:32AM +0530, inventsekar wrote:
>> > >>> A brute force grep in the kernel shows that there are 130493 "
>> const "
>> > in there
>> > Hi Hofrat,
>> > 1. may i know the command to do this above grep please..
>>
>> $ grep -cre " const " * | more
>>
>> will give you the " const " count per file - and then put a shell loop
>> around it
>>
>> $ SUM=0 ; for N in `grep -cre " const " * | cut -f 2 -d ":" ` ; do let
>> SUM=$SUM+$N ; done ; echo $SUM
>>
>> ...as noted "brute force"
>>
>> > 2. (and the opposite) may i know the command to grep other type of
>> > variables/structures
>>
>> well if you want to know how to do that then you do need to look at basics
>> if regular expressions are not clear then you might want to look at
>> those first. And grep really is not the right tool to search for specific
>> structures and their use use something like cscope.
>>
>> Try to focus on doing work you understand including the tools and
>> processes
>> around it - if you just are looking for a fast way of getting X patches
>> into the kernel you are wasting your time. What the work from Bhumika
>> Goyal
>> shows is that its not about the complexity of the change but about the
>> systematic approach based on using understanding a problem class,
>> translating
>> it to an abstract representation amenable to tools (coccinelle in this
>> case)
>> and documenting her understanding in the commit messages to each patch.
>>
>> thx!
>> hofrat
>>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180914/473af293/attachment.html>