Re: Linux kernel module - memory allocation

[jan.de.kruyf@gmail.com]

On Tuesday, May 19, 2015 at 7:30:37 AM UTC+2, q.kontinuum wrote:

> I think I might be a different learning type. 

Age related I guess.
I was forced to take your way with an ethernet driver for an arm board since no good example was available (at least not for what I wanted) And oh boy was I bitten in the foot! But it is running now.

> > 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?
> 

file:///usr/gnat/share/doc/gnat/html/gnat_rm_2.html#SEC6 (on my machine)
-------------------- 	
pragma No_Run_Time;

This is an obsolete configuration pragma that historically was used to setup what is now called the "zero footprint" library. It causes any library units outside this basic library to be ignored. The use of this pragma has been superseded by the general configurable run-time capability of GNAT where the compiler takes into account whatever units happen to be accessible in the library.
--------------------
> > It just needs porting back to x86.
> 
> Not, when the target ist my raspberry pi :-)

Shows you how bad I am at reading books ;) I should have said "kernelspace" perhaps. 


> 
> 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.
> 

Well, yes. At the moment I am going to set up an ioctl communication channel and a page of 'dual port' memory as a buffer that can be read / written on both sides, so we have 'zero-copying' communication. I need that for speed. And ioctl works nicely also as a debugging tool. It will allow me to ask specific info from kernelspace  at runtime.


> 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
> 

Yes, i take it you did see my post about the load of other switches the module building process inserts into the call to gcc.

And you just gave me an idea. 
I think I am going to run gcc with no package System.Memory (thats where gcc looks when there is a memory request) just to see what happens. Normally gcc calls for some form of malloc, but perhaps in kernel mode it acts differently.

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

j.