help about handling interrupts

help about handling interrupts

[Igor Pascual Sagastagoitia]

I am learning ADA95 and I am searching for an example of attaching a
procedure when an interrupts rises.
I read the RM95 but I dont understand it too well because of my
language.
I am programming under GNAT 3.10 for a Linux platform.
Thanks in advance.

Re: help about handling interrupts

[Markus Kuhn]

Igor Pascual Sagastagoitia wrote:
> 
> I am learning ADA95 and I am searching for an example of attaching a
> procedure when an interrupts rises.
> I read the RM95 but I dont understand it too well because of my
> language.
> I am programming under GNAT 3.10 for a Linux platform.

Like many of those hardware related questions, this is more a matter
of your operating system than a matter of Ada. Therefore you should
look into the Linux kernel first how interrupt handling is
done there and not into the RM.

User processes cannot directly handle interrupts under Linux.
If you want to write an interrupt handler yourself, you have to
do this in a loadable kernel module. You can write loadable kernel
modules in Ada just like you can do this in C. You have to call a
kernel function at module load time that registers your Ada
procedure as an interrupt handler, and then the Linux kernel
will call your Ada procedure whenever this interrupt comes in.

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: help about handling interrupts

[Jerry van Dijk]

Markus Kuhn (Markus.Kuhn@cl.cam.ac.uk) wrote:

: Igor Pascual Sagastagoitia wrote:
: > 
: > I am learning ADA95 and I am searching for an example of attaching a
: > procedure when an interrupts rises.
: > I read the RM95 but I dont understand it too well because of my
: > language.
: > I am programming under GNAT 3.10 for a Linux platform.

: Like many of those hardware related questions, this is more a matter
: of your operating system than a matter of Ada. Therefore you should
: look into the Linux kernel first how interrupt handling is
: done there and not into the RM.

Unless Igor was refering to the package Ada.Interrupts, which is
AFAIK not yet supported under Linux, so it would be difficult to
show a working example anyway.

Jerry.
-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada

Re: help about handling interrupts

[Robert Dewar]

Markus says

<<No, this was quoted from the GNAT RM, not the Ada RM. The sentence
"Followed ..." refers to what GNAT does, although the first sentence
seems to be copied from the Ada RM. Annex C of the GNAT RM is a
very minimalistic approach of writing this annex. For most sections,
it just says "Followed." without any further discussion of how the
implementors did it. Some more information about for which targets
GNAT supports Ada handeled interrupts would have been been nice.
The annex C of the GNAT RM reads very much like a text that has
been written for the sole purpose of fulfilling the standard by the
letter.
>>

GNAT *does* implement interrupts on all targets, it maps signals to
interrupts, so the GNAT reference manual is correct! We have lots of
customers using interrupts on a wide variety of systems.

Re: help about handling interrupts

[Robert Dewar]

Markus said

<<I'd love to comment on the POSIX.5 way of handling signals,
but the copy of POSIX.5 which I ordered from IEEE many weeks ago
still has not arrived. Standards that are only available on
paper from low-quality-of-service publishers like IEEE and ISO
are a VERY BAD THING, not at all helpful for the spread of the
technology. If you are the editor of any standard, *please* make
sure that the documents are available freely online as well as
from a big book publisher such as Springer or Addison Wesley, and not
only from buerocrats like ISO/IEEE. The AdaRM has proofed
that this is easily possible (I got my AdaRM from Springer delivered
within 3 days, at the price of a normal university textbook),
so why not also for POSIX?
>>


The easily in "easily possible" here is absurd. All the Ada achievment
shows is that it is possible, but it was FAR from easy. It took a huge
amount of work, and at one point it looked like the entire ISO
standardization process would fail because of the insistence on free
availability.

Yes it is possible, but the experience with the Ada standard is not
encouraging at all from the point of view of setting a copyable
precedent. Standards organizations are VERY insistent about obtaining
and exploiting copyrights, it is one of the major sources of funding
for these organizations.

Re: help about handling interrupts

[Matthew Heaney]

In article <3529047A.44EE08B8@cl.cam.ac.uk>, Markus Kuhn
<Markus.Kuhn@cl.cam.ac.uk> wrote:

>Igor Pascual Sagastagoitia wrote:
>> 
>> I am learning ADA95 and I am searching for an example of attaching a
>> procedure when an interrupts rises.
>> I read the RM95 but I dont understand it too well because of my
>> language.
>> I am programming under GNAT 3.10 for a Linux platform.
>
>Like many of those hardware related questions, this is more a matter
>of your operating system than a matter of Ada. Therefore you should
>look into the Linux kernel first how interrupt handling is
>done there and not into the RM.
>
>User processes cannot directly handle interrupts under Linux.
>If you want to write an interrupt handler yourself, you have to
>do this in a loadable kernel module. You can write loadable kernel
>modules in Ada just like you can do this in C. You have to call a
>kernel function at module load time that registers your Ada
>procedure as an interrupt handler, and then the Linux kernel
>will call your Ada procedure whenever this interrupt comes in.

I don't understand this response.

In Ada 95, you attach protected procedure of a protected object to an
interrupt.  Section 19.6, INTERRUPT HANDLING, in Norm Cohen's book is
dedicated to this very topic.

No, the OS doesn't make any difference.  The syntax for specifying an
interrupt handler in Ada is the same for all platforms.

Basically, you declare a protected object, and use pragma Attach_Handler to
designate a protected procedure as the interrupt handler.

See also pragma Interrupt_Handler and package Ada.Interrupts.

Re: help about handling interrupts

[Markus Kuhn]

Matthew Heaney wrote:
> Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:
> >User processes cannot directly handle interrupts under Linux.
> >If you want to write an interrupt handler yourself, you have to
> >do this in a loadable kernel module. You can write loadable kernel
> >modules in Ada just like you can do this in C. You have to call a
> >kernel function at module load time that registers your Ada
> >procedure as an interrupt handler, and then the Linux kernel
> >will call your Ada procedure whenever this interrupt comes in.
> 
> I don't understand this response.
> 
> In Ada 95, you attach protected procedure of a protected object to an
> interrupt.  Section 19.6, INTERRUPT HANDLING, in Norm Cohen's book is
> dedicated to this very topic.
> 
> No, the OS doesn't make any difference.  The syntax for specifying an
> interrupt handler in Ada is the same for all platforms.
> 
> Basically, you declare a protected object, and use pragma Attach_Handler to
> designate a protected procedure as the interrupt handler.
> 
> See also pragma Interrupt_Handler and package Ada.Interrupts.

Have you actually tried this under Linux? There is no way this
will work. Unless you do lots of special things (see the documentation
of how to compile a Linux loadable kernel module), GNAT will produce
an ELF output file that can only be started as a normal user
process. And normal user processes CAN NOT handle interrupts
directly. The sections in the RM you quoted have been intended
for compilers for embedded systems, where the Ada runtime library
does everything that on a PC is done by the operating system or
where there is a special real-time operating system used.
All this does not apply for a compiler that produces normal
Unix application programms.

The Ada standard does not make it unnecessary that you get
familiar with the mechanisms of your operating system if you
want to access the hardware directly, including handling
interrupts! One of the main purpose of a time-sharing operating
system is to prevent you from directly accessing the hardware.

The GNAT RM says:

"C.3.1(20-21): Protected Procedure Handlers 

Whenever possible, the implementation should allow interrupt handlers to
be called directly by the hardware. Followed on any target where the
underlying operating system permits such direct calls."

Well, any Unix operating system I know is not a platform that
allows procedures in user processes to be called by hardware
interrupts. This has nothing to do with the programming language
used, this is an operating system issue.

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: help about handling interrupts

[Samuel Tardieu]

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

Igor> I am learning ADA95 and I am searching for an example of
Igor> attaching a procedure when an interrupts rises.  I read the RM95
Igor> but I dont understand it too well because of my language.  I am
Igor> programming under GNAT 3.10 for a Linux platform.

Markus> Like many of those hardware related questions, this is more a
Markus> matter of your operating system than a matter of
Markus> Ada. Therefore you should look into the Linux kernel first how
Markus> interrupt handling is done there and not into the RM.

Markus> User processes cannot directly handle interrupts under Linux.

I'm afraid you are talking about different things; it looks like Igor
means "signal" when he writes "interrupt", while you mean "hardware
interrupt".

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: help about handling interrupts

[Robert Dewar]

Matthew says

<<>User processes cannot directly handle interrupts under Linux.
>If you want to write an interrupt handler yourself, you have to
>do this in a loadable kernel module. You can write loadable kernel
>modules in Ada just like you can do this in C. You have to call a
>kernel function at module load time that registers your Ada
>procedure as an interrupt handler, and then the Linux kernel
>will call your Ada procedure whenever this interrupt comes in.

I don't understand this response.

In Ada 95, you attach protected procedure of a protected object to an
interrupt.  Section 19.6, INTERRUPT HANDLING, in Norm Cohen's book is
dedicated to this very topic.

No, the OS doesn't make any difference.  The syntax for specifying an
>>



And I don't understand Matthew's response. If you take the attitude that
an interrupt in the RM really means an interrupt (as opposed to some kind
of operating system signal), then it is perfectly legitimate to reject all
attempts at attaching interrupt handlers on a system which does not allow
you to define an interrupt routine in the environment in which you are trying
to compile (e.g. user mode on NT or Unix).

Re: help about handling interrupts

[Matthew Heaney]

In article <dewar.891959182@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>Matthew says
>
><<>User processes cannot directly handle interrupts under Linux.
>>If you want to write an interrupt handler yourself, you have to
>>do this in a loadable kernel module. You can write loadable kernel
>>modules in Ada just like you can do this in C. You have to call a
>>kernel function at module load time that registers your Ada
>>procedure as an interrupt handler, and then the Linux kernel
>>will call your Ada procedure whenever this interrupt comes in.
>
>I don't understand this response.
>
>In Ada 95, you attach protected procedure of a protected object to an
>interrupt.  Section 19.6, INTERRUPT HANDLING, in Norm Cohen's book is
>dedicated to this very topic.
>
>No, the OS doesn't make any difference.  The syntax for specifying an
>>>
>
>
>
>And I don't understand Matthew's response. If you take the attitude that
>an interrupt in the RM really means an interrupt (as opposed to some kind
>of operating system signal), then it is perfectly legitimate to reject all
>attempts at attaching interrupt handlers on a system which does not allow
>you to define an interrupt routine in the environment in which you are trying
>to compile (e.g. user mode on NT or Unix).

I think there's a terminology problem.  When the original poster said
"attach an interrupt," I interpreted him to mean "attach a procedure to a
UNIX signal."  I suppose if you're writing a device driver, and you need an
"interrupt service routine (ISR)," then I don't think you can use a
protected object.  But if you mean "UNIX signal," then you can (at least I
hope you can!).

Re: help about handling interrupts

[Markus Kuhn]

Robert A Duff wrote:
> >...The sections in the RM you quoted have been intended
> >for compilers for embedded systems, ...
> 
> True, but when the compiler is generating code for normal user-mode
> processes running under an operating system, it makes perfect sense to
> map those features onto the software interrupts supported by the OS --
> "signals" in Unix, "ASTs" in VMS.  It might also make sense in some
> operating systems to write installable device drivers and whatnot in
> Ada.

Fully agreed.

> >The GNAT RM says:
> You mean the Ada RM!

No, this was quoted from the GNAT RM, not the Ada RM. The sentence
"Followed ..." refers to what GNAT does, although the first sentence
seems to be copied from the Ada RM. Annex C of the GNAT RM is a
very minimalistic approach of writing this annex. For most sections,
it just says "Followed." without any further discussion of how the
implementors did it. Some more information about for which targets
GNAT supports Ada handeled interrupts would have been been nice.
The annex C of the GNAT RM reads very much like a text that has
been written for the sole purpose of fulfilling the standard by the
letter.

> >"C.3.1(20-21): Protected Procedure Handlers
> >
> >Whenever possible, the implementation should allow interrupt handlers to
> >be called directly by the hardware. Followed on any target where the
> >underlying operating system permits such direct calls."

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: help about handling interrupts

[Markus Kuhn]

Samuel Tardieu wrote:
> I'm afraid you are talking about different things; it looks like Igor
> means "signal" when he writes "interrupt", while you mean "hardware
> interrupt".

It seems to be a common problem that programming beginners mix
up terminology and get therefore confusing answers here, such as
"signal" versus "hardware interrupt" under Unix or "memory
access" versus "i/o port access". "Interrupt" can under Unix
indeed also refer to one special type of signal, the SIGINT
that a process receives when you press Ctrl-C on its controlling
shell.

Handling Unix signals is described in POSIX.1 if you want to use
the C API or in POSIX.5 if you want to use a native Ada API.
See the FLORIST package on <http://www.cs.fsu.edu/~baker/florist.html>.

A note about the pain with standards:

I'd love to comment on the POSIX.5 way of handling signals,
but the copy of POSIX.5 which I ordered from IEEE many weeks ago
still has not arrived. Standards that are only available on
paper from low-quality-of-service publishers like IEEE and ISO
are a VERY BAD THING, not at all helpful for the spread of the
technology. If you are the editor of any standard, *please* make
sure that the documents are available freely online as well as
from a big book publisher such as Springer or Addison Wesley, and not
only from buerocrats like ISO/IEEE. The AdaRM has proofed
that this is easily possible (I got my AdaRM from Springer delivered
within 3 days, at the price of a normal university textbook),
so why not also for POSIX?

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: help about handling interrupts

[Dale Stanbrough]

Robert Dewar writes:

"Yes it is possible, but the experience with the Ada standard is not
 encouraging at all from the point of view of setting a copyable
 precedent. Standards organizations are VERY insistent about obtaining
 and exploiting copyrights, it is one of the major sources of funding
 for these organizations."


Why don't they just license the publishing to other people, and collect
the money that way? Seems they could save a bit on in house printing,
distribution etc.

Dale

Re: The pain with standards

[Markus Kuhn]

Robert Dewar wrote:
[Ada95 standard is freely available online]
> [...] All the Ada achievment
> shows is that it is possible, but it was FAR from easy. It took a huge
> amount of work, and at one point it looked like the entire ISO
> standardization process would fail because of the insistence on free
> availability.
> 
> Yes it is possible, but the experience with the Ada standard is not
> encouraging at all from the point of view of setting a copyable
> precedent. Standards organizations are VERY insistent about obtaining
> and exploiting copyrights, it is one of the major sources of funding
> for these organizations.

Ada95 is not the first and only freely available ISO standard.
Many of the newer standards of the SGML committee are available
online, some of the CLNP OSI standards are. Standards like ISO 8859,
ODA, ISO 9660, and many more are freely available from ECMA, etc.
I am sure I could easily come up with a list of over 30 information
technology ISO standards that are available freely from non-ISO
sources. The trick usually is that a standard is developed outside
the ISO system by the volunteering experts and published first through
another body (ECMA, IETF, etc.), and then just sent through the ISO
fast-track procedure for the ratification.

ISO' central secretariat in Geneva is funded only to 20% from document
sales and to 80% from member organization contributions (according
to an ISO brochure that they gave me in 1995). It also escapes my
understanding, why you need ~130 employees in Geneva to handle
a set of only around 12 000 documents and why it is necessary for
ISO to operate their own very expensive printshop. I visited ISO CS
a few years ago and I had a very clear impression that there is
much opportunity for cost savings in this quasi-monopoly company.
Their business model seems to have been unchanged since when they
started to publish screw thread and chemical product standards in
the 1940s. It needs an urgent upgrade for information technology
standards, which are mostly ignored if not every developer has them
instantly anhd freely available online when needed. Much very useful
work by volunteer experts (who are not paid by the document fees!)
is prevented from being applied in the real world by the restricted
document distribution policies of ISO and its member bodies.

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