<div dir="ltr">Don't be discouraged!<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 14, 2018 at 12:53 PM inventsekar <<a href="mailto:inventsekar@gmail.com">inventsekar@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span style="color:rgb(40,38,37);font-family:"source sans pro","open sans",georgia,serif;font-size:15px;white-space:pre-wrap;background-color:rgb(255,255,255)">Hi,  for the past three years I have been trying hard to do Linux kernel development, but, with No success.</span><div dir="auto"><span style="color:rgb(40,38,37);font-family:"source sans pro","open sans",georgia,serif;font-size:15px;white-space:pre-wrap;background-color:rgb(255,255,255)"><br></span></div><div dir="auto"><span style="color:rgb(40,38,37);font-family:"source sans pro","open sans",georgia,serif;font-size:15px;white-space:pre-wrap;background-color:rgb(255,255,255)"> I don't know what is the exact reason...maybe, I</span><span style="background-color:rgb(255,255,255);color:rgb(40,38,37);font-family:"source sans pro","open sans",georgia,serif;font-size:15px;white-space:pre-wrap"> 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.</span></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu 13 Sep, 2018, 11:37 AM Nicholas Mc Guire, <<a href="mailto:der.herr@hofr.at" target="_blank">der.herr@hofr.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Sep 13, 2018 at 09:12:32AM +0530, inventsekar wrote:<br>
> >>> A brute force grep in the kernel shows that there are 130493 " const "<br>
> in there<br>
> Hi Hofrat,<br>
> 1. may i know the command to do this above grep please..<br>
<br>
$ grep -cre " const " * | more<br>
<br>
will give you the " const " count per file - and then put a shell loop around it<br>
<br>
$ SUM=0 ; for N in `grep -cre " const " * | cut -f 2 -d ":" ` ; do let SUM=$SUM+$N ; done ; echo $SUM<br>
<br>
...as noted "brute force"<br>
<br>
> 2. (and the opposite) may i know the command to grep other type of<br>
> variables/structures<br>
<br>
well if you want to know how to do that then you do need to look at basics<br>
if regular expressions are not clear then you might want to look at<br>
those first. And grep really is not the right tool to search for specific<br>
structures and their use use something like cscope.<br>
<br>
Try to focus on doing work you understand including the tools and processes<br>
around it - if you just are looking for a fast way of getting X patches<br>
into the kernel you are wasting your time. What the work from Bhumika Goyal<br>
shows is that its not about the complexity of the change but about the <br>
systematic approach based on using understanding a problem class, translating<br>
it to an abstract representation amenable to tools (coccinelle in this case)<br>
and documenting her understanding in the commit messages to each patch. <br>
<br>
thx!<br>
hofrat <br>
</blockquote></div>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
<a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</blockquote></div>