Linux kernel module - memory allocation

Linux kernel module - memory allocation

[q.kontinuum]

I'm new to this group, new to Ada programming, and a bit out of touch with
Linux driver development for some time. Since I want to learn Ada and want
to get back in touch with Linux I'm trying to implement a driver for my 
raspberry-pi, to access a DS18B20 temperature sensor via onewire protocol.

The steps I already took was to implement a small wrapper in C to link 
with a first Hello world module in Ada and to access the hr_timer of the 
Linux kernel (here I again used to wrapper and called it from Ada to avoid 
cloning the whole hrtimer struct from Linux kernel header files)

Where I'm getting stuck now is a function returning a String. I simplified 
the function to this:

   function UInt2String(I : Integer) return String is
   begin      
      return "";
   end;

As soon as this function is used somewhere, I can't load the module. 
Here is the kernel log output when I try to load the module:

May 18 10:19:39 localhost kernel: [87978.938801] wrapper: 
   Unknown symbol system__secondary_stack__ss_allocate (err 0)
May 18 10:19:39 localhost kernel: [87978.938812] wrapper: 
   Unknown symbol system__secondary_stack__ss_release (err 0)
May 18 10:19:39 localhost kernel: [87978.938819] wrapper: 
   Unknown symbol system__secondary_stack__ss_mark (err 0)
May 18 10:19:39 localhost kernel: wrapper: 
   Unknown symbol system__secondary_stack__ss_allocate (err 0)
May 18 10:19:39 localhost kernel: wrapper: 
   Unknown symbol system__secondary_stack__ss_release (err 0)
May 18 10:19:39 localhost kernel: wrapper: 
   Unknown symbol system__secondary_stack__ss_mark (err 0)

I will need to store a binary tree later on to store the addresses of the 
devices found on the onewire bus. In C, I'd probably use kmalloc and 
casts to allocate memory for a node of the tree. How should I do that in 
Ada?

Sorry if this is a stupid question. I'm entirely happy with a RTFM + link
to a good M on this topic.

Re: Linux kernel module - memory allocation

[Niklas Holsti]

On 15-05-18 11:27 , q.kontinuum wrote:
> I'm new to this group, new to Ada programming, and a bit out of touch with
> Linux driver development for some time. Since I want to learn Ada and want
> to get back in touch with Linux I'm trying to implement a driver for my
> raspberry-pi, to access a DS18B20 temperature sensor via onewire protocol.

I don't know much about the Linux driver environment, but perhaps I can 
help you a bit...

Do you mean a real "driver", either kernel-linked or a loadable module? 
Or do you mean user-land SW to operate the sensor through some existing 
I/O driver for the I/O channel? From the error messages you get, I guess 
you want to make a loadable driver module.

Which Ada compiler are you using? Do you use some specific compiler 
switches to adapt it to the driver environment?

> The steps I already took was to implement a small wrapper in C to link
> with a first Hello world module in Ada and to access the hr_timer of the
> Linux kernel (here I again used to wrapper and called it from Ada to avoid
> cloning the whole hrtimer struct from Linux kernel header files)

Yes, it is often simpler to have a C wrapper, if the header files are 
complex. But GNAT can also translate some C headers into Ada 
declarations automatically.

> Where I'm getting stuck now is a function returning a String. I simplified
> the function to this:
>
>     function UInt2String(I : Integer) return String is
>     begin
>        return "";
>     end;
>
> As soon as this function is used somewhere, I can't load the module.
> Here is the kernel log output when I try to load the module:
>
> May 18 10:19:39 localhost kernel: [87978.938801] wrapper:
>     Unknown symbol system__secondary_stack__ss_allocate (err 0)

A function that returns a value of run-time dynamic size, such as the 
unconstrained String in your example, needs support from the Ada 
run-time system (RTS). In the GNAT compiler, this support takes the form 
of a "secondary stack" that is used to hold such data of dynamic size, 
but with first-in-first-out life-times.

The error message you get shows that the kernel (of course) does not 
provide this Ada-specific support.

You could try with a constrained string subtype, say String(1 .. 10), 
but I suspect that you should be using some very specific GNAT switches 
to completely eliminate any dependency on the GNAT RTS (which will of 
course constrain the kind of Ada code you can run in this environment).

> I will need to store a binary tree later on to store the addresses of the
> devices found on the onewire bus. In C, I'd probably use kmalloc and
> casts to allocate memory for a node of the tree. How should I do that in
> Ada?

If kmalloc is what your environment (kernel) provides, I suppose that is 
what you should use. Perhaps you can wrap it up as a user-defined Ada 
"storage pool" (see the Ada RM 13.11) which would let you use the "new" 
statement, or you can write an Ada binding in the same way as for your C 
wrappers. kmalloc seems to return a C "void *". Assuming that this is 
implemented as an address, you should be able to use the predefined Ada 
package System.Address_To_Access_Conversions to convert the kmalloc 
result to a pointer of any type you want (but beware memory alignment 
errors -- the documentation for kmalloc that I found did not promise to 
return memory aligned in any particular way).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Linux kernel module - memory allocation

[q.kontinuum]

Hi, thanks a lot for the fast reply.

In comp.lang.ada, you wrote:
> On 15-05-18 11:27 , q.kontinuum wrote:
> Do you mean a real "driver", either kernel-linked or a loadable module? 

Yes, I'm aiming for a loadable kernel module.

> Which Ada compiler are you using? Do you use some specific compiler 
> switches to adapt it to the driver environment?

I'm using gnat. Command line to compile a 
gnatmake -a -s -mcmodel=kernel ...

> But GNAT can also translate some C headers into Ada 
> declarations automatically.

I should look into that. Good to know.

> You could try with a constrained string subtype, say String(1 .. 10), 

I assume if I use that within a function, I'd run into the same problem
because the function might be called more often, thus still requiring
dynamic allocation. Since I know that only one instance of the driver 
will be used single threaded, and only one buffer is used, I could 
declare it in the modules declaration section rather than the function.

> what you should use. Perhaps you can wrap it up as a user-defined Ada 
> "storage pool" (see the Ada RM 13.11) which would let you use the "new" 
> statement

This sounds like just what I need - I will definitely have a closer look
at it, thanks a bunch!

> or you can write an Ada binding in the same way as for your C 
> wrappers. kmalloc seems to return a C "void *". Assuming that this is 
> implemented as an address, you should be able to use the predefined Ada 
> package System.Address_To_Access_Conversions to convert the kmalloc 
> result to a pointer of any type you want (but beware memory alignment 
> errors -- the documentation for kmalloc that I found did not promise to 
> return memory aligned in any particular way).

Thanks, sounds like a good starting point to gather some further 
information myself.

Re: Linux kernel module - memory allocation

[Niklas Holsti]

On 15-05-18 12:19 , q.kontinuum wrote:
> Hi, thanks a lot for the fast reply.
>
> In comp.lang.ada, you wrote:
>> On 15-05-18 11:27 , q.kontinuum wrote:
>> Do you mean a real "driver", either kernel-linked or a loadable module?
>
> Yes, I'm aiming for a loadable kernel module.

Ok. I don't think many people have tried this with GNAT or Ada -- I 
don't know of any others. Do you know anyone who has done it?

I you haven't already done so, you should find out what "elaboration" 
means in Ada (= initializations before the main subprogram starts), and 
either ensure that your driver somehow does it, although it has no main 
subprogram -- perhaps some part of the driver should call "adainit" 
explicitly -- or perhaps by ensuring that your Ada code needs no 
elaboration. Look into the pragmas Preelaborate and No_Elaboration_Code 
(the latter is GNAT-specific).

The Gnat User Guide section 
http://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/building_executable_programs_with_gnat.html#binding-with-non-ada-main-programs 
may be useful.

>> Which Ada compiler are you using? Do you use some specific compiler
>> switches to adapt it to the driver environment?
>
> I'm using gnat. Command line to compile a
> gnatmake -a -s -mcmodel=kernel ...

I couldn't find any AdaCore documentation about -mcmodel=kernel with 
GNAT. Hmm...

>> You could try with a constrained string subtype, say String(1 .. 10),
>
> I assume if I use that within a function, I'd run into the same problem
> because the function might be called more often, thus still requiring
> dynamic allocation.

I don't follow. if you say

    subtype String10 is String(1 .. 10);

then every object of type String10 has a static size. Local variables of 
that type will be allocated on the (primary, standard) stack, but that 
does not count as dynamic allocation.

Perhaps you are thinking of some part of your real application, not 
strings at all?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Linux kernel module - memory allocation

[Simon Clubley]

On 2015-05-18, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> On 15-05-18 12:19 , q.kontinuum wrote:
>> Hi, thanks a lot for the fast reply.
>>
>> In comp.lang.ada, you wrote:
>>> On 15-05-18 11:27 , q.kontinuum wrote:
>>> Do you mean a real "driver", either kernel-linked or a loadable module?
>>
>> Yes, I'm aiming for a loadable kernel module.
>
> Ok. I don't think many people have tried this with GNAT or Ada -- I 
> don't know of any others. Do you know anyone who has done it?
>

Yes, I have but I remember very rapidly deciding to give up once I tried
to do something "real".

Also, it was over a decade ago, so I no longer remember any details.

Here's a Usenet post of mine which has showed up in one of the Usenet
archives; the response to the post has some information:

http://computer-programming-forum.com/44-ada/86f1b921763bcbde.htm

(I browse with a locked down Firefox browser on Linux; I don't know
anything about this website other than it was the first match in a
Google search.)

The comp.lang.ada title was:

Using GNAT in Linux kernel modules, was: Re: Free RTOS with support for Ada ?

Also check out section 16.16 (Writing Linux Modules) at:

http://www.pegasoft.ca/resources/boblap/16.html

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Linux kernel module - memory allocation

[jan.de.kruyf]

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/

Then you really need the kernel source or the kernel dev headers to be able to do any module, unless Android is more advanced in this respect (which I doubt)

Next get the source of a tiny module with the makefile and study it until you know it backward, including all the kernel special tricks.

then run the make file and see how the build process pulls itself into lots of knots in order to do the right thing. You might have to find out how to make it speak to you. On Linux it is like this: 'make V=1'.

Then you might be able to extract some Ada definitions with a play module that includes the C headerfiles of interest. (and some of those then come from the kernel dev packet.) To do that you need to repeat the -I stanzas that you saw when you build the module above, on the command line, so you get your c header files from the right places. (some of the -I's need path expansion since the module make process changes directory to the place where the kernel-dev files are)

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.

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. But you can definitely not use the normal gnat runtime since it pulls clib in.
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.

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. 
As soon as the compiler complains about some missing symbol with lots of underscores in it, you can be sure that something is missing in your runtime and you either need to drop that language feature or you need to fix up your runtime.

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

We are willing to learn . . . 


Now let me quickly read Simons great find at pegasoft.

May the peace be with you.

j.

Re: Linux kernel module - memory allocation

[q.kontinuum]

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

Re: Linux kernel module - memory allocation

[jan.de.kruyf]

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.

Re: Linux kernel module - memory allocation

[q.kontinuum]

On 2015-05-19, jan.de.kruyf@gmail.com <jan.de.kruyf@gmail.com> wrote:
> 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.

Hehe :-) I wrote an ethernet-driver for a Z80 (don't ask...) ~14 years
ago. I feel your pain. But that time I did read the specs, and much 
good did it to me. In the end I had to get a logic analyzer to check
what was going on on the bus because the chip didn't abide the specs.

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

Ok, I guess I should be able to find this somewhere. Although 
a quick google search did not show a relevant package.

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

Yes, although I didn't look into that much. I just looked up a short 
tutorial like "getting started", and took the parameters from there.
Quite simple, actually. 

This is my current Makefile at the moment:
https://github.com/thors/ada/blob/master/driver/Makefile

Br,
Thorsten

Re: Linux kernel module - memory allocation

[jan.de.kruyf]

On Tuesday, May 19, 2015 at 9:57:09 AM UTC+2, q.kontinuum wrote:

> Hehe :-) I wrote an ethernet-driver for a Z80 (don't ask...) ~14 years
> ago. I feel your pain. But that time I did read the specs, and much 
> good did it to me. In the end I had to get a logic analyzer to check
> what was going on on the bus because the chip didn't abide the specs.
> 

what specs. There were no specs !
Just do a soft reset to load the parameters you just wrote, monkeys. this was the phy chip.

> >
> > file:///usr/gnat/share/doc/gnat/html/gnat_rm_2.html#SEC6 (on my machine)
> 
> Ok, I guess I should be able to find this somewhere. Although 
> a quick google search did not show a relevant package.
> 

GNAT Reference Manual - GCC - GNU
https://gcc.gnu.org/onlinedocs/gnat_rm/
This manual contains useful information in writing programs using the GNAT compiler. It includes information on implementation dependent characteristics of ...

cheers,
j.

Re: Linux kernel module - memory allocation

[Mart van de Wege]

jan.de.kruyf@gmail.com writes:

> On Tuesday, May 19, 2015 at 9:57:09 AM UTC+2, q.kontinuum wrote:
>
>> >
>> > file:///usr/gnat/share/doc/gnat/html/gnat_rm_2.html#SEC6 (on my machine)
>> 
>> Ok, I guess I should be able to find this somewhere. Although 
>> a quick google search did not show a relevant package.
>> 
>
> GNAT Reference Manual - GCC - GNU

On a Debian machine you would find that in the gnat-doc package.

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

Re: Linux kernel module - memory allocation

[jan.de.kruyf]

On Tuesday, May 19, 2015 at 12:28:04 PM UTC+2, Mart van de Wege wrote:

> "We will need a longer wall when the revolution comes."
>     --- AJS, quoting an uncertain source.

Wait for me to start programming, a longer Wall will definitely be in order.

may the peace of no walls be with you,

j.

Re: Linux kernel module - memory allocation

[G.B.]

On 19.05.15 10:06, jan.de.kruyf@gmail.com wrote:
> GNAT Reference Manual - GCC - GNU
> https://gcc.gnu.org/onlinedocs/gnat_rm/
> This manual contains useful information in writing programs using the GNAT compiler. It includes information on implementation dependent characteristics of ...

FTR:
file:///${GNAT_INSTALL_DIR}/share/doc/

Re: Linux kernel module - memory allocation

[Simon Wright]

jan.de.kruyf@gmail.com writes:

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

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

Has anyone pointed to http://wiki.osdev.org/Ada_Bare_bones yet?

Re: Linux kernel module - memory allocation

[jan.de.kruyf]

On Tuesday, May 19, 2015 at 11:52:48 AM UTC+2, Simon Wright wrote:

> 
> Has anyone pointed to http://wiki.osdev.org/Ada_Bare_bones yet?

Valid point, but I do think that for kernel at least some of Luke's restrictions can be alleviated by a good runtime that takes Kernel programming restrictions into account.

Also for the STM32f4xx runtime I sneaked a few facilities in that were sorely missed.

I will try to split that thing off for you on github, I did not do the interrupts though, mainly for lack of motivation. Or maybe I first wanted to get a proof of concept and I dont need them at the moment.


cheers

j.

Re: Linux kernel module - memory allocation

[q.kontinuum]

On 2015-05-18, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2015-05-18, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:

>> Ok. I don't think many people have tried this with GNAT or Ada -- I 
>> don't know of any others. Do you know anyone who has done it?
>>
>
> Yes, I have but I remember very rapidly deciding to give up once I tried
> to do something "real".

I'm not 100% confident that I will manage to do all I wanted to in 
Ada... But I want to give it a try :-)
I already started to use imported C-functions in some places 
for convenience. Currently, the idea is to keep the interface small.

> Also, it was over a decade ago, so I no longer remember any details.
>
> Here's a Usenet post of mine which has showed up in one of the Usenet
> archives; the response to the post has some information:
>
> http://computer-programming-forum.com/44-ada/86f1b921763bcbde.htm

Yes, I remember I found that post when I started to research...
My current plan is to implement the higher functionality 
of the driver in Ada (onewire device search, message composition 
and decoding for temperature reading), and maybe use
the existing raspberry gpio kernel module to set the right signals
on the bus. 

> Also check out section 16.16 (Writing Linux Modules) at:
>
> http://www.pegasoft.ca/resources/boblap/16.html

Yes, I had a look there and found some first ideas. However,
they just mentioned I had to register a license, without telling me
how to. So, the hello-world they provided did not work for me.

Br,
Thorsten

Re: Linux kernel module - memory allocation

[rrr.eee.27]

On Monday, May 18, 2015 at 9:48:26 PM UTC+2, q.kontinuum wrote:
> My current plan is to implement the higher functionality 
> of the driver in Ada (onewire device search, message composition 
> and decoding for temperature reading), and maybe use
> the existing raspberry gpio kernel module to set the right signals
> on the bus. 

I suppose you know that the Linux kernel already has a 1-wire filesystem ...

If you want to implement the main 1-wire functions yourself you might look at the One_Wire package hierarchy of AVR-Ada [1]

HTH
    RE

[1] https://sourceforge.net/p/avr-ada/code/ci/master/tree/avr/onewire/

> Br,
> Thorsten

Re: Linux kernel module - memory allocation

[q.kontinuum]

On 2015-05-18, rrr.eee.27@gmail.com <rrr.eee.27@gmail.com> wrote:
> On Monday, May 18, 2015 at 9:48:26 PM UTC+2, q.kontinuum wrote:
>> My current plan is to implement the higher functionality 
>> of the driver in Ada (onewire device search, message composition 
>> and decoding for temperature reading), and maybe use
>> the existing raspberry gpio kernel module to set the right signals
>> on the bus. 
>
> I suppose you know that the Linux kernel already has a 1-wire filesystem ...

Yes, I know. For me it's mainly an exercise.

> If you want to implement the main 1-wire functions yourself you might 
> look at the One_Wire package hierarchy of AVR-Ada [1]

I will try it by myself first. If I can't do it, maybe I will have a look
at your source. Nevertheless, thanks already. I was not aware there is a
Onewire package for Ada.

Br,
Thorsten

Re: Linux kernel module - memory allocation

[q.kontinuum]

On 2015-05-18, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> On 15-05-18 12:19 , q.kontinuum wrote:
>> Yes, I'm aiming for a loadable kernel module.
>
> Ok. I don't think many people have tried this with GNAT or Ada -- I 
> don't know of any others. Do you know anyone who has done it?

Not really. I found some initial information, although it looked
quite outdated:

http://www.pegasoft.ca/resources/boblap/16.html
(latest update 2009)

> I you haven't already done so, you should find out what "elaboration" 
> means in Ada (= initializations before the main subprogram starts), and 
> either ensure that your driver somehow does it, although it has no main 
> subprogram -- perhaps some part of the driver should call "adainit" 
> explicitly -- or perhaps by ensuring that your Ada code needs no 
> elaboration. Look into the pragmas Preelaborate and No_Elaboration_Code 
> (the latter is GNAT-specific).

That's why I use the C-wrapper. The wrapper implements 
    int init_module(void)
and 
    void cleanup_module(void)

which calls the correspondent function/procedure in the Ada module.

I found two ways to do this, one is to re-implement the behaviour 
of the kernel MODULE_LICENSE macro, the other is to write a 
C-wrapper using this macro and calling the Ada-entry points from 
there. The second approach seemed to be the easier one.

BTW: My current attempts are on github:
https://github.com/thors/ada
 
> The Gnat User Guide section 
> http://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/building_executable_programs_with_gnat.html#binding-with-non-ada-main-programs 
> may be useful.

Thanks, I will have a look.

>>> Which Ada compiler are you using? Do you use some specific compiler
>>> switches to adapt it to the driver environment?
>>
>> I'm using gnat. Command line to compile a
>> gnatmake -a -s -mcmodel=kernel ...
>
> I couldn't find any AdaCore documentation about -mcmodel=kernel with 
> GNAT. Hmm...

GNAT is gcc-based. -mcmodel=kernel is required by gcc to generate code
for kernel-space.
 
https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html

>>> You could try with a constrained string subtype, say String(1 .. 10),
>>
>> I assume if I use that within a function, I'd run into the same problem
>> because the function might be called more often, thus still requiring
>> dynamic allocation.
>
> I don't follow. if you say
>
>     subtype String10 is String(1 .. 10);
>
> then every object of type String10 has a static size. Local variables of 
> that type will be allocated on the (primary, standard) stack, but that 
> does not count as dynamic allocation.

Ok, I still have a lot to learn how the different ways of allocation work
in Ada...

Br,
Thorsten

Re: Linux kernel module - memory allocation

[jan.de.kruyf]

>GNAT is gcc-based. -mcmodel=kernel is required by gcc to generate code 
>for kernel-space. 

Thanks for that Thorsten.

I do see that the kernel building process adds about a dozen more switches. Perhaps we need to use some of those as well when building the Ada part . . .?

cheers,

Jan.