From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "q.kontinuum" Newsgroups: comp.lang.ada Subject: Re: Linux kernel module - memory allocation Date: Tue, 19 May 2015 05:30:30 +0000 (UTC) Organization: Aioe.org NNTP Server Message-ID: References: <8759d49e-c30a-4c71-a3e5-fd7a818a30f6@googlegroups.com> Reply-To: nntp@thorzten.de NNTP-Posting-Host: 2Re8NKytgV911fAPUMdAmQ.user.speranza.aioe.org X-Complaints-To: abuse@aioe.org User-Agent: slrn/1.0.1 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:25914 Date: 2015-05-19T05:30:30+00:00 List-Id: On 2015-05-18, 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 :-)