2nd help about handling HW interrupt and apologizes.

2nd help about handling HW interrupt and apologizes.

[jtapasai]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]


Firstly, I would like to apologize of my first post, wich wasn�t clear enough.
Secondly, I would like to thank you for your help.

My problem is that I must program an interrupt service routine that is
executed when the predeterminated IRQ is rised, because the data adquisition
card has finished the A/Dconversion.

I have read all the responses, but there is already two doubts in my mind :
 - Does Linux allow to define a hardware interrupt service routine ?
 - Does GNAT for Linux support this feature ?

Thanks in advance.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re: 2nd help about handling HW interrupt and apologizes.

[Markus Kuhn]

jtapasai@bipa162.bi.ehu.es wrote:
> Secondly, I would like to thank you for your help.
> My problem is that I must program an interrupt service routine that is
> executed when the predeterminated IRQ is rised, because the data adquisition
> card has finished the A/Dconversion.
> 
> I have read all the responses, but there is already two doubts in my mind :
>  - Does Linux allow to define a hardware interrupt service routine ?

Yes, but only inside the kernel.

>  - Does GNAT for Linux support this feature ?

Yes, because GNAT allows you to call all the C kernel functions
that you need to call to get this done and because the Linux
kernel is also compiled by gcc and therefore GNAT output can
easily be linked into the kernel.

My previous reply still applies:

Only code in the kernel, not normal user processes can handle
interrupt, this is completely independent of the programming
language.

In the kernel, you have to call request_irq() in order to register
your interrupt handler. For instance, the keyboard driver
in /usr/src/linux/drivers/char/keyboard.c contains the line

 request_irq(KEYBOARD_IRQ, keyboard_interrupt, 0, "keyboard", NULL);

to register its interrupt handler routine. You can call this
C routine also from Ada using pragma Import. The important thing
is that your Ada program has either to be compiled into the kernel
or you have to load your program as a loadable kernel module
using the system calls described on "man 2 modules".

Recommended reading to get started with Linux device driver
programming:

http://www.redhat.com:8080/HyperNews/get/khg.html
http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html
http://sunsite.unc.edu/mdw/HOWTO/mini/Modules.html
http://sunsite.unc.edu/mdw/linux.html

Unfortunately, I do not know any text that specificaly discusses
writing Linux device drivers in Ada, but I do not think many
special considerations beyond the normal Ada/C interfacing
issues have to be made. Read the sections of the GNAT user manual
that discuss how you can add Ada code to C programs such that
C can call Ada routines.

It is just important that GNAT does not do any fancy things with
its tasking run-time system once your Ada code is running inside
the kernel, because you do not have the system call interface
available inside the kernel.

Has anyone here practical experience with using GNAT output
as part of the Linux kernel? What happens if I call Ada routines
without calling 

   __gnat_initialize();
   adainit();

and

   adafinal();
   __gnat_finalize();

which might not work inside the kernel?

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: 2nd help about handling HW interrupt and apologizes.

[Geert Bosch]

Andi Kleen <ak@muc.de> wrote:
   To just get the job done it is probably easier to just write a small
   stub kernel driver in C that communicates with the Ada program running
   in userspace over a device or a netlink socket.

Of course you'll have exactly the same problems when you write these
drivers in C as when you write them in Ada! As you mentioned it is
not safe to use the C run-time library as well. So, yes, you should
write your code using a very limited subset of the language and you'll
have to know what kind of code your compiler generates.

For example when using GNAT it is possible to get almost identical
code as when using the GNU C compiler if you just limit yourself to
what would be possible in C. It is easy to do this experiment yourself
and look at the generated code; this is something you should do in
any case when writing code like system kernel modules. 

Regards,
   Geert

Re: 2nd help about handling HW interrupt and apologizes.

[Simon Wright]

Andi Kleen <ak@muc.de> writes:

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

I suppose it's possible that GNORT (GNAT with NO Run Time, I think)
might help here. Don't know if you can get it without being a customer
of ACT, though.

Re: 2nd help about handling HW interrupt and apologizes.

[Andi Kleen]

Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> writes:

> jtapasai@bipa162.bi.ehu.es wrote:
> > Secondly, I would like to thank you for your help.
> > My problem is that I must program an interrupt service routine that is
> > executed when the predeterminated IRQ is rised, because the data adquisition
> > card has finished the A/Dconversion.
> > 
> > I have read all the responses, but there is already two doubts in my mind :
> >  - Does Linux allow to define a hardware interrupt service routine ?
> 
> Yes, but only inside the kernel.
> 
> >  - Does GNAT for Linux support this feature ?
> 
> Yes, because GNAT allows you to call all the C kernel functions
> that you need to call to get this done and because the Linux
> kernel is also compiled by gcc and therefore GNAT output can
> easily be linked into the kernel.
> 
> My previous reply still applies:
> 
> Only code in the kernel, not normal user processes can handle
> interrupt, this is completely independent of the programming
> language.
> 
> In the kernel, you have to call request_irq() in order to register
> your interrupt handler. For instance, the keyboard driver
> in /usr/src/linux/drivers/char/keyboard.c contains the line
> 
>  request_irq(KEYBOARD_IRQ, keyboard_interrupt, 0, "keyboard", NULL);
> 
> to register its interrupt handler routine. You can call this
> C routine also from Ada using pragma Import. The important thing
> is that your Ada program has either to be compiled into the kernel
> or you have to load your program as a loadable kernel module
> using the system calls described on "man 2 modules".

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. 

To just get the job done it is probably easier to just write a small
stub kernel driver in C that communicates with the Ada program running
in userspace over a device or a netlink socket.

-Andi

Re: Using GNAT for Linux kernel hacking

[Markus Kuhn]

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: <http://www.cl.cam.ac.uk/~mgk25/>

Re: 2nd help about handling HW interrupt and apologizes.

[Andi Kleen]

Geert Bosch <geert@gonzo.sun3.iaf.nl> writes:

> Andi Kleen <ak@muc.de> wrote:
>    To just get the job done it is probably easier to just write a small
>    stub kernel driver in C that communicates with the Ada program running
>    in userspace over a device or a netlink socket.
> 
> Of course you'll have exactly the same problems when you write these
> drivers in C as when you write them in Ada! As you mentioned it is
> not safe to use the C run-time library as well. So, yes, you should
> write your code using a very limited subset of the language and you'll
> have to know what kind of code your compiler generates.

Because the complete kernel is written in C linux has already most required
runtime library support for C. Of course the in-kernel environment is not
full ISO-C compliant. The user callable library is very different, and there
are even a few language differences:
- Initialisation of local arrays does not work as expected, because gcc
calls bzero() for that and the kernel runtime library only has memset.
- Unitialised global or static variables are not guranteed to be zero
at kernel start, because the kernel doesn't clear the BSS segment.
- More complex long long arithmetic [which is not ISO C anyways] like the 
diviosn probably won't work on 32bit machines because the kernel doesn't 
include the necessary code from libgcc.

Overall I would say it is safer to write kernel code in C than in Ada,
simply because it is a much better understood topic. Also the kernel
includes rely heavily on include functions, C macros and inline assembler
so you might have a hard time to write a ada binding for that.

> For example when using GNAT it is possible to get almost identical
> code as when using the GNU C compiler if you just limit yourself to
> what would be possible in C. It is easy to do this experiment yourself
> and look at the generated code; this is something you should do in
> any case when writing code like system kernel modules. 

This is true, you'll probably need to invest much more exploration work
for a Ada module - I think it is not worth it when a small stub is 
sufficient.

-Andi