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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,641105de50ec2788 X-Google-Attributes: gid103376,public From: Markus Kuhn Subject: Re: Using GNAT for Linux kernel hacking Date: 1998/04/10 Message-ID: <352E296B.23588C29@cl.cam.ac.uk>#1/1 X-Deja-AN: 342758163 Content-Transfer-Encoding: 7bit References: <6gft3m$rib$1@nnrp1.dejanews.com> <352BB2AE.1DC7325E@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Cambridge University, Computer Laboratory Newsgroups: comp.lang.ada Date: 1998-04-10T00:00:00+00:00 List-Id: Andi Kleen wrote: > I would be careful with Ada programs in kernel space. GNAT has a rather > complex runtime library that is required to work, and this library > might not work completely in kernel space. For example there are several > caveats: > - Memory allocation works differently than in user space. > - The kernel stack is limited to 4K (and it is only safe to use 2-3K > to keep enough space for interrupt handlers) > - There is no libc in kernel space, so the runtime library might need > stubs. > - Ada tasking and protected types probably won't work [unless it is > especially ported] > > I'm not saying that it is impossible to write ada kernel drivers, just > that it might require more work than one would naively think at first. > Of course once the runtime library is ported it'll be easier. Well, the situation is not that much different from C. If you write C code in the kernel, you also have lots of special rules to follow. You can't use malloc() and other standard library functions in C as well. You won't be allowed to "with" most of the common Ada packages just like you can't "#include" most of the C libary functions in the kernel. The only advantage that C has over Ada and C++ for kernel programming is that in C, there is much less going on "between the lines" of your source code, i.e. less automatically inserted code for finalization, tasking, synchronization, memory deallocation, exception handling, garbage collection, etc. that could cause bad surprises if executed in the kernel. Also package elaboration might have to be done differently in a kernel context, i.e. at boot or module load time. There sure must be a way to deactivate or prevent these between-the- lines calls to the run-time library. After all, how else would you be able to use Ada in order to write such a run-time library in the first place? Do the Controlled and Restricted pragmas offer something along those lines? Is there any documentation available about the interface between the code generated by GNAT and the GNAT runtime library, especially concerning things like tasking and memory management? I have found some old documentation in http://www.cs.fsu.edu/~baker/ftp/pub/PART/GNARL/gid-1.32.ps.gz Is this still up-to-date? Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: