Re: Linux kernel module - memory allocation

["q.kontinuum" <achsis_of_elvis@yahoo.co.uk>]

On 2015-05-18, jan.de.kruyf@gmail.com <jan.de.kruyf@gmail.com> wrote:
> Hallo,
> I am feeling brave at the moment so I am messing with this stuff.
> You might be more informed than I am at this moment on certain aspects, 
> but perhaps some of my observations might be of help.
>  
> So this is  what I found:
>
> read this book until you know it backward:
>
> https://lwn.net/Kernel/LDD3/

I think I might be a different learning type. I rarely read something
forward and backward. I read once to get a grasp of the basic concepts,
then I prefer to get cracking until I hit the first block in the road, 
then I try to figure out, what was the crucial part I missed.

> Then you really need the kernel source or the kernel dev headers to be 
> able  to do any module, 

Sure, the headers. For the raspberry there seems to be no raspbian
header package, so I got the kernel source tree, but usually the 
headers should suffice.

> unless Android is more advanced in this respect
> (which I doubt)

? I'm not doing anything with Android...

> Then you might be able to extract some Ada definitions 
> with a play module that includes the C headerfiles of interest. 

I didn't use yet any C headers in Ada. Definitely something 
I should look into.

> Then there are lots of booby traps in the Ada versions, because gnat does 
> not know everything. for instance a little program that is defined as 
> an inline in a headerfile is taken for gospel by gnat but it will not 
> link when you try to use it, since there is no code for it in the kernel. 
> So you must write a wrapper in c.

So I noticed in case of udelay... But no big deal, easy to notice,
easy to work around.

> Somewhere in the discussion I saw "no runtime". This is obsolete now.
> you are supposed to have some runtime even if it is empty, I suppose.

I didn't find anything about this. Do you have some additional information?

> I did make myself a small runtime for my Arm work which seems to 
> behave quite well. It does have a secondary stack also. 
> It just needs porting back to x86.

Not, when the target ist my raspberry pi :-)

> In that runtime you need some of the stuff that the compiler wants 
> in order to successfully build your program. Like a way of obtaining 
> memory when you initialize a struct from a pointer.

Currently I tend to use some static memory instead. kmalloc should be
used scarcely, and I don't need much memory anyway. I just need a 
buffer for messages to send and an array to store the addresses of
the onewire devices. (Well, actually I'm not sure I need that. The
search algorithm should work when the driver just gets last found
address + last fork point [point, where an address with bit=1 and 
another with bit=0 exists and decision was taken to search in one 
direction] in order to follow the other direction next time.)

Everything more complex should be done in userspace anyway.

> So I am still looking into the runtime thing, but there is a lot to 
> look into at the moment. And the runtime is sort of cut cake. I will 
> probably put some wrappers into it for the more delicate stuff.
>
> At the same time I did decide to use an existing piece of c code to 
> give me a framework in which to mess with Ada. A bit later I might 
> find ways of expanding the Ada bit, but at the moment I am happy 
> with working code no matter what language.
>
> Btw do tell us where you found this funny gnatmake switch 
> "gnatmake .. -mcmodel=kernel ...

As I wrote in another thread, it's a gcc feature. 
https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html

> May the peace be with you.
And with you :-)