Linux Kernel in Ada. Repost

Linux Kernel in Ada. Repost

[Bruce MacDonald]

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

(Reposted at the suggestion of T. E. D.)

I�m sorry about the poor use of bandwith, I was unaware there would be a
problem with posting on Maundy Thursday. :)

I have been casting about trying to find out if anyone is rewriting the Linux
kernel in a high level language, such as Ada.
Is anyone else interested in a project like this? Would the Intermetrics C2Ada
tool be the appropriate starting place for this project?
Thank you,

Bruce MacDonald

What doesn't kill you, makes you bitter and cynical.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Linux Kernel in Ada. Repost

[Matthew Heaney]

Bruce MacDonald <microbards@my-dejanews.com> writes:

> I have been casting about trying to find out if anyone is rewriting the Linux
> kernel in a high level language, such as Ada.

I don't know.


> Is anyone else interested in a project like this? 

Yes, I would be.

But I would also look at the work being done by the Debian people on
HURD.  That OS is still in its early stages.


> Would the Intermetrics C2Ada tool be the appropriate starting place
> for this project?

How writing some device drivers in Ada first, to get things moving
along.

Re: Linux Kernel in Ada. Repost

[Jeffrey D. Cherry]

Bruce MacDonald wrote:
> 
> I have been casting about trying to find out if anyone is rewriting the Linux
> kernel in a high level language, such as Ada.
> Is anyone else interested in a project like this? Would the Intermetrics C2Ada
> tool be the appropriate starting place for this project?

I'd be interested ... sounds like fun.  I'm not sure about the C2Ada
tool since I have no experience with it myself.  However, I don't see
how it could hurt and at the very least would automate at least a
portion of the process.

Regards,

Jeffrey D. Cherry
Senior IV&V Analyst
Logicon Geodynamics

Re: Linux Kernel in Ada. Repost

[Corey Ashford]

"Jeffrey D. Cherry" wrote:
> 
> Bruce MacDonald wrote:
> >
> > I have been casting about trying to find out if anyone is rewriting the Linux
> > kernel in a high level language, such as Ada.
> > Is anyone else interested in a project like this? Would the Intermetrics C2Ada
> > tool be the appropriate starting place for this project?
> 
> I'd be interested ... sounds like fun.  I'm not sure about the C2Ada
> tool since I have no experience with it myself.  However, I don't see
> how it could hurt and at the very least would automate at least a
> portion of the process.
> 

I'd like to ask what the long-term goal of this would be?

Without a considerable amount of work, I don't know how you'd keep the Ada kernel
up with the C kernel.  About the only way that would happen is if you could convert
Torvald and his groupies to use Ada, and the chances of that are about nil at this
point, don't you think?

- Corey

Re: Linux Kernel in Ada. Repost

[Jeffrey D. Cherry]

Corey Ashford wrote:
> 
> "Jeffrey D. Cherry" wrote:
> >
> > Bruce MacDonald wrote:
> > >
> > > I have been casting about trying to find out if anyone is rewriting the Linux
> > > kernel in a high level language, such as Ada.
> > > Is anyone else interested in a project like this? Would the Intermetrics C2Ada
> > > tool be the appropriate starting place for this project?
> >
> > I'd be interested ... sounds like fun.  I'm not sure about the C2Ada
> > tool since I have no experience with it myself.  However, I don't see
> > how it could hurt and at the very least would automate at least a
> > portion of the process.
> >
> 
> I'd like to ask what the long-term goal of this would be?
> 
> Without a considerable amount of work, I don't know how you'd keep the Ada kernel
> up with the C kernel.  About the only way that would happen is if you could convert
> Torvald and his groupies to use Ada, and the chances of that are about nil at this
> point, don't you think?
> 
> - Corey

Corey,

I can't speak for anyone else, but for me the goal would be just to do
it.  I think it would be both educational and a good experience.

I agree that it is unlikely to convert Torvald and his fellow
programmers from their C base to Ada.  Personally I have a lot of
respect for that group and wouldn't want to change a good thing.  I view
the project as imitation being the most sincere form of flattery.

Regards
Jeffrey D. Cherry
Logicon Geodynamics

Re: Linux Kernel in Ada. Repost

[me]

 
Why don't we write a brand new OS in Ada?  It will be all in 100% pure
Ada. It will be the most powerfull, most reliable, most flexible, 
100% up-time, 24 hrs per day, 365 days per year, and runs on 1000 CPU's 
without a sweat, a kicks Ass OS, it will mnake Solaris and Linux and 
the Hurd and VMS and OS390 look like little babies in front of it.

That is what we need to do. Don't limit yourself by what is out today, look
ahead, make a revolutionary OS that will rock the world, an OS like
no other out there. It will detect every hardware you throw at it, it will 
tune itself as it runs, never ever crashes, comes pre-packged with
the most powerfull development tools ever made, and so flexible and 
configurable that it will make Unix looks like a dead rock in still 
water in comparison.

It will all be free source and open source of course. 

This is the kind of OS I'll be happy to work on with the others, but I 
would not be interested in just a copy of an existing OS.

me

Re: Linux Kernel in Ada. Repost

[Larry Kilgallen]

In article <7el9so$geb@drn.newsguy.com>, me@me writes:
>  
> Why don't we write a brand new OS in Ada?  It will be all in 100% pure
> Ada. It will be the most powerfull, most reliable, most flexible, 
> 100% up-time, 24 hrs per day, 365 days per year, and runs on 1000 CPU's 
> without a sweat, a kicks Ass OS, it will mnake Solaris and Linux and 
> the Hurd and VMS and OS390 look like little babies in front of it.

Why some of us don't is that applications drive the operating system,
and the last successful commercial operating system that was actually
brand new was probably 16 years ago.

Windows 2000 brings along the baggage of DOS, which brought along  the
baggage of CP/M.  VMS brought the baggage of RSX.  AS/400 brought the
baggage of System 36 and System 38.

Additionally, it seems doubtful the assembled multitude could
agree on a feature set.  File versions, security constraints,
file naming, hardware platform, etc. are all sufficient to
bring to the discussion more heat than light.

> Why don't we write a brand new OS in Ada?  It will be all in 100% pure
> Ada. It will be the most powerfull, most reliable, most flexible, 
> 100% up-time, 24 hrs per day, 365 days per year, and runs on 1000 CPU's 
> without a sweat, a kicks Ass OS, it will mnake Solaris and Linux and 
> the Hurd and VMS and OS390 look like little babies in front of it.

Choice of implementation language does not give all those qualities
to an operating system.  It may make achieving them easier, but it
does not even guarantee that they are possible.

Larry Kilgallen

Re: Linux Kernel in Ada. Repost

[David Starner]

Larry Kilgallen wrote:
> Why some of us don't is that applications drive the operating system,
> and the last successful commercial operating system that was actually
> brand new was probably 16 years ago.
[...]
> Additionally, it seems doubtful the assembled multitude could
> agree on a feature set.  File versions, security constraints,
> file naming, hardware platform, etc. are all sufficient to
> bring to the discussion more heat than light.

Well, at least write a new operating system, even if you decide on
making it Posix complaint for compatibilty. Converting the Linux kernel
to Ada seems like an incredibly pointless exersize, worthy only of
language bigots. Writing a new kernel to be faster, more stable, easier
to work and more extendable then Linux, OTOH, is worthy of any hacker.

(Look at Gnome for example. While they had a goal to replace KDE, they
decided to make technical improvements along the way where ever they
could.)

-- 
David Starner - OSU student - dstarner98@aasaa.ofe.org
If you want a real optimist, look up Ray Bradbury. Guy's nuts. 
He actually likes people. -David Brin

Re: Linux Kernel in Ada. Repost

[Brian Rogoff]

On Fri, 9 Apr 1999, David Starner wrote:
> Larry Kilgallen wrote:
> > Why some of us don't is that applications drive the operating system,
> > and the last successful commercial operating system that was actually
> > brand new was probably 16 years ago.
> [...]
> > Additionally, it seems doubtful the assembled multitude could
> > agree on a feature set.  File versions, security constraints,
> > file naming, hardware platform, etc. are all sufficient to
> > bring to the discussion more heat than light.
> 
> Well, at least write a new operating system, even if you decide on
> making it Posix complaint for compatibilty. Converting the Linux kernel
> to Ada seems like an incredibly pointless exersize, worthy only of
> language bigots. Writing a new kernel to be faster, more stable, easier
> to work and more extendable then Linux, OTOH, is worthy of any hacker.

Exactly. A rewrite of the Linux kernel in Ada might be a fun hack, but 
isn't likely to attract the same interest Linux has, since Linux is the 
best Linux out there. 

Take a look at any of the innovative free kernels out there, like 
EROS, http://www.cis.upenn.edu/~eros/. Rewriting EROS in Ada (the EROS
kernel is currently written in C++) would have higher "gee-whiz" value 
IMO. 

-- Brian

Re: Linux Kernel in Ada. Repost

[Robert Dewar]

In article <370E6473.AD97011A@aasaa.ofe.org>,
  David Starner <dstarner98@aasaa.ofe.org> wrote:
> making it Posix complaint for compatibilty.
                  ^^^^^^^^^

Yes well I guess that does capture some people's thinking
about Posix :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Linux Kernel in Ada. Repost

[Hans N. Beck]

Larry Kilgallen schrieb:

> In article <7el9so$geb@drn.newsguy.com>, me@me writes:
> >
> > Why don't we write a brand new OS in Ada?  It will be all in 100% pure
> > Ada. It will be the most powerfull, most reliable, most flexible,
> > 100% up-time, 24 hrs per day, 365 days per year, and runs on 1000 CPU's
> > without a sweat, a kicks Ass OS, it will mnake Solaris and Linux and
> > the Hurd and VMS and OS390 look like little babies in front of it.
>
> Why some of us don't is that applications drive the operating system,
> and the last successful commercial operating system that was actually
> brand new was probably 16 years ago.
>
> Windows 2000 brings along the baggage of DOS, which brought along  the
> baggage of CP/M.  VMS brought the baggage of RSX.  AS/400 brought the
> baggage of System 36 and System 38.
>
> Additionally, it seems doubtful the assembled multitude could
> agree on a feature set.  File versions, security constraints,
> file naming, hardware platform, etc. are all sufficient to
> bring to the discussion more heat than light.
>
> > Why don't we write a brand new OS in Ada?  It will be all in 100% pure
> > Ada. It will be the most powerfull, most reliable, most flexible,
> > 100% up-time, 24 hrs per day, 365 days per year, and runs on 1000 CPU's
> > without a sweat, a kicks Ass OS, it will mnake Solaris and Linux and
> > the Hurd and VMS and OS390 look like little babies in front of it.
>
> Choice of implementation language does not give all those qualities
> to an operating system.  It may make achieving them easier, but it
> does not even guarantee that they are possible.

>

That's right, but if one begin from scratch with another language like C in
view,perhaps there are new ideas for designing a OS, new point of views to
the
problem how manage hardware resources quickly, safe, fault-tolerant (and
other things) to many processes, users, tasks ... Perhaps, from a new Ada
kernel
there come new impulses how Ada is good for, how it can be used as well.
I think, a interesting idea if not used to rebuild the Linux as Linux as it
is now
with the only difference in the language used.

Hans


--
            Dipl.-Ing. Hans N. Beck
 --------------------------------------------
  Technischer + didaktischer Computereinsatz
 --------------------------------------------
        Waldstr. 28, D-75045 Walzbachtal

        \   Tel: +49 (0)7203 922280   /
         \  Fax: +49 (0)7203 922281  /
          \ Handy:    0177 5383233  /

           eMail: hnbeck@t-online.de

Re: Linux Kernel in Ada. Repost

[Tarjei Tj�stheim Jensen]

me@me wrote in message <7el9so$geb@drn.newsguy.com>...
>
>Why don't we write a brand new OS in Ada?  It will be all in 100% pure
>Ada. It will be the most powerfull, most reliable, most flexible,
>100% up-time, 24 hrs per day, 365 days per year, and runs on 1000 CPU's
>without a sweat, a kicks Ass OS, it will mnake Solaris and Linux and
>the Hurd and VMS and OS390 look like little babies in front of it.


It would be more useful to write useful utilities for Linux in Ada or extend
Linux with Ada software.

A few things that could/should be improved; NIS and printing.

NIS has real problems with even reasonable sized files (or maps as they call
it). E.g. there are problems with the number of members of groups. You cannot
have password aging with NIS. NIS+ is supposed to have its own problems and is
supposedly not an option.

There is a lot that can be done about printing in Unix. Especially with regards
to proper handling of printers, access control, etc. HP does reasonably well
with their own printers with the Jetadmin software for HP-UX and Solaris. SGI
seems to do reasonably well with their scripts (although I don't like their
lpsched implementation). A common problem is that the printing system have to
be shut down before you can do certain operations, like adding or removing a
printer. Sometime it is hard to find where the host keeps certain information
about ques on the remote machine.

I'm sure others will tell you more things that needs to be done.

Greetings,

Re: Linux Kernel in Ada. Repost

[bill_]

In article <7elrg5$egk2@ftp.kvaerner.com>, "Tarjei says...
>
 
>It would be more useful to write useful utilities for Linux in Ada or extend
>Linux with Ada software.
>
 
It is kind'a hard to write Linux or Unix stuff in Ada, becuase the Posix
Ada binding do not seem to work well or even documented. The Posix Ada
bindings for linux (there is now even an RPM for these for Linux!) do not
have an API document to tell one how to use them to write the sort of stuff
you are talking about.

Bill

Re: Linux Kernel in Ada. Repost

[Tarjei Tj�stheim Jensen]

bill_@nospam wrote:

> In article <7elrg5$egk2@ftp.kvaerner.com>, "Tarjei says...
> >
>
> >It would be more useful to write useful utilities for Linux in Ada or extend
> >Linux with Ada software.
> >
>
> It is kind'a hard to write Linux or Unix stuff in Ada, becuase the Posix
> Ada binding do not seem to work well or even documented. The Posix Ada
> bindings for linux (there is now even an RPM for these for Linux!) do not
> have an API document to tell one how to use them to write the sort of stuff
> you are talking about.
>

If you don't like what is there, make your own. In order to get a decent result
one should probably read one of W. Rickard Stevens programming books. He uses C,
but there should be no problem translating to Ada.

Regardless of what one does it is neccessary to understand the problem domain in
order to provide a sensible solution.


Greetings,

Re: Linux Kernel in Ada. Repost

[Mich]

In article <370F025C.4C821FEC@online.no>, "Tarjei says...
 
>bill_@nospam wrote:
>
>> In article <7elrg5$egk2@ftp.kvaerner.com>, "Tarjei says...
>> >
>>
>> >It would be more useful to write useful utilities for Linux in Ada or extend
>> >Linux with Ada software.
>> >
>>

>> It is kind'a hard to write Linux or Unix stuff in Ada, becuase the Posix
>> Ada binding do not seem to work well or even documented. The Posix Ada
>> bindings for linux (there is now even an RPM for these for Linux!) do not
>> have an API document to tell one how to use them to write the sort of stuff
>> you are talking about.
>>
>


>If you don't like what is there, make your own. In order to get a decent result
>one should probably read one of W. Rickard Stevens programming books. He uses C,
>but there should be no problem translating to Ada.
>
>Regardless of what one does it is neccessary to understand the problem domain in
>order to provide a sensible solution.
>

Oh PLEASE !!
 
While Ada programmers wasting their time each writing the same binding
to Unix (which they need to even start writing the real stuff to use 
the binding) the world is passing them on the fast track.

Do you think it is trivial to write a fully working Ada posix binding?
by saying just go read a book to do it, shows that you really do not
know what is involved here. Have a look at the current Ada binding posix
code just to see what is there. Remember, you have to implement all
the posix standard, not just 5 easy little functions.

Do you think those Java API's that Sun with its hundreds of programmers
working for years on them, is something one person can just go build
if they don't like what is not out there?

Ada's problem is that there is no central group that handles it as far as
devloping API's, libraries, etc.. and to coordinates things. This central
group can then organize who is working on what, to eliminate waste and
duplication. Something like goes on in the Linux world to some extent.

Java has Sun. VB and VC++ has MS. Ada used to have the defense department,
but it divorsed it after more than 20 years difficult marriage. 
(btw, I think the Linux ALT group are doing a great job, may be they
can drive more Ada projects like this one, and people will help them). 

I have nothing against the cowboy mentaility of, if you don't like something,
go re-write it, sure, this works for small stuff, but for large complicated
stuff, be real, it will not work.  
 
Ok, I don't like windows, I am going now to go rewrite it.

Mich.

Re: Linux Kernel in Ada. Repost

[Tarjei Tj�stheim Jensen]

Mich@western_world_somehwere wrote :
>Do you think it is trivial to write a fully working Ada posix binding?
>by saying just go read a book to do it, shows that you really do not
>know what is involved here. Have a look at the current Ada binding posix
>code just to see what is there. Remember, you have to implement all
>the posix standard, not just 5 easy little functions.

Please readjust your expectations. It is usually not neccessary to implement
the full Posix to write an application. I have done the same with a part of the
OS/2 API that I wanted to use. It is work, but not neccessarily a lot of work.

>Ada's problem is that there is no central group that handles it as far as
>devloping API's, libraries, etc.. and to coordinates things. This central
>group can then organize who is working on what, to eliminate waste and
>duplication. Something like goes on in the Linux world to some extent.


That is entirely true. There is a tendency to do everything the official way.
That means that nothing happens for years. However there is hope; there are
people who seem to spend a lot of time creating Ada code for the common public.

It would be nice to have an library architect (or a number of them) for
mainstream Ada (mainstream here means general computing). It may very well be
that this is required for Ada to reach the big time in our lifetime.

>Java has Sun. VB and VC++ has MS. Ada used to have the defense department,
>but it divorsed it after more than 20 years difficult marriage.
>(btw, I think the Linux ALT group are doing a great job, may be they
>can drive more Ada projects like this one, and people will help them).


Gnat has done more for Ada than anything else the DoD has ever done. If Ada
goes fully mainstream it will probably be professor Dewars fault :-) This does
not belittle what others have done, just an acknowledgement that Gnat is the
foundation.


Greetings,

Re: Linux Kernel in Ada. Repost

[Robert Dewar]

In article <7enpj3$je53@ftp.kvaerner.com>,

> Gnat has done more for Ada than anything else the DoD has
> ever done.

Well thanks for the thought, but let's be fair here. GNAT
was a DoD funded project, without the DoD (and in
particular Chris Anderson, the DoD project director
for Ada 9X), there would have been no GNAT!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

OpenToken project announcement

[dennison]

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

In article <7enpj3$je53@ftp.kvaerner.com>,
  "Tarjei Tj�stheim Jensen" <tarjei.jensen@kvaerner.no> wrote:

> That means that nothing happens for years. However there is hope; there are
> people who seem to spend a lot of time creating Ada code for the common
public.
>

In that vein, I'd like to announce the initial release of the token analysis
packages I developed at my work to the Ada OpenSource community, under the
aegis of the OpenToken Project. A webpage for the project is at
http://www.telepath.com/dennison/Ted/OpenToken/OpenToken.html ).

The goal of the project is to further the development of the reusable
exensible token analysis packages, and eventually to provide similar packages
to support parsing activites.

The initial version of the pacakges is downloadable from the web page in
gnu-zipped and Windows zipped forms. It currently contains only a small readme
file for documentation, and generic tokenizer objects for character sets,
identifiers, integer literals, real literals, keywords, and line comments.

In the next release I hope to provide a simple example, and perhaps more
documentation and recognizers. Any help anyone can provide in these areas
(particularly new recognizers) would be greatly appreciated, of course.

I'd also like to have input from people who have experience in writing
compilers on the algorithms used in this package. Until I can generate some
benchmarks against lex-generated analyziers, that is my only way of
evaluating the advisability of the approach I took for the analysis engine.
But I do realize such folk tend to be incredibly busy.

I'd like to take a moment to list the motivations that caused this release:

FlightSafety's decision to release this code seemed to be based on (this is
*not* an official company statement!):

  o  The possibility of increasing the utility and stability of the package
without dedicating its own manpower to do so.
  o  A percieved moral obligation to put something back into the OSS community
that they derive so much benifit from.

My reasons for wanting to release this code as OSS are:
  o  The ability to use this highly useful tool no matter where my career may
take me.
  o  It seemed like a good project to base my master's thesis on. :-)


T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Linux Kernel in Ada. Repost

[Robert Dewar]

In article <7en7kg$o9d@drn.newsguy.com>,
  Mich@western_world_somehwere wrote:
> Do you think it is trivial to write a fully working Ada
> posix binding? by saying just go read a book to do it,
> shows that you really do not know what is involved here.
> Have a look at the current Ada binding posix code just to
> see what is there. Remember, you have to implement all
> the posix standard, not just 5 easy little functions.

First of all one thing to realize is that a *thin* binding
to Posix is trivial. Indeed I would guess that the SGI
binding generator would automatically get you 98% or more
of the way there, and even if you had to do it by hand,
it would not be more than a week's work.

However, the relatively thick binding for Ada prescribed
by the IEEE standard is indeed a larger effort, and one
that is not something you can knock off quickly. The reason
is that you are building something at a significantly
higher abstraction level.

Indeed to call this a "binding" is a bit peculiar
(certainly at some level of change-of-abstraction, we
do not use the word binding, the Win32 interface is not
a binding to the NT kernel -- ok, not a fair comparison
of course but you see the idea).

Was it a good idea to decide on a thick binding? I think
not, and have always felt this, but there has always been
a lot of controversy.

Thin bindings

Advantages
   easy to learn (same knowledge base as underlying system)
   easy to implement
   already documented in texts etc

Disadvantages
   level of abstraction is lower than one would like

Thick Bindings

Advantages
   operate at a higher level of abstraction more suitable
   for Ada.

Disadvantage
   much harder to implement, may not get implemented widely
   or quicly.

   new ada-specific knowledge base required

   no existing texts etc

My opinion is that the best approach is to go for thin
bindings, which can be largely generated automatically.
Then let individual applications layer on top of these
choosing abstractions particularly suited for the
application at hand (as indeed a good C programmer
would do to -- if you can find one who understands
abstraction :-)

But as I say this is an old argument.

Just remember no one requires you to use the IEEE bindings
to POSIX as *the* one and only way to interface to Unix
style functionality -- go ahead and bind thin if you
prefer.



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Linux Kernel in Ada. Repost

[Kevin]

In article <7ep7hh$on3$1@nnrp1.dejanews.com>, Robert says...
 
>
>My opinion is that the best approach is to go for thin
>bindings, which can be largely generated automatically.

Any plans of having such a thin binding as part of the 
GNAT package that comes with the GNAT compiler? 

Kevin
 

Re: Linux Kernel in Ada. Repost

[Harry Tanovich]

Robert Dewar wrote:

> In article <7en7kg$o9d@drn.newsguy.com>,
>   Mich@western_world_somehwere wrote:
> > Do you think it is trivial to write a fully working Ada
> > posix binding? by saying just go read a book to do it,
> > shows that you really do not know what is involved here.
> > Have a look at the current Ada binding posix code just to
> > see what is there. Remember, you have to implement all
> > the posix standard, not just 5 easy little functions.
>
> First of all one thing to realize is that a *thin* binding
> to Posix is trivial. Indeed I would guess that the SGI
> binding generator would automatically get you 98% or more
> of the way there, and even if you had to do it by hand,
> it would not be more than a week's work.

What is the "SGI binding generator"?

Re: Linux Kernel in Ada. Repost

[Robert Dewar]

In article <7evh4l$ogk$1@news-1.news.gte.net>,
  Harry Tanovich <harryt@gte.net> wrote:
> What is the "SGI binding generator"?
>
This is answered in a separate thread with the above title

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Linux Kernel in Ada. Repost

[Jerry van Dijk]

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

Tarjei Tj�stheim Jensen (tarjei@online.no) wrote:


: If you don't like what is there, make your own. In order to get a decent result
: one should probably read one of W. Rickard Stevens programming books. He uses C,
: but there should be no problem translating to Ada.
i
For reference (as Mr. Stevens wrote a number of very useful books), that would
refer to:

	"Advanced Programming in the UNIX Environment"
	W.Richard Stevens

	My copy say:
	Addison-Wesley, 1992
	Ninth printing, 1995
	ISBN 0-201-56317-7


--
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: Linux Kernel in Ada. Repost

[Jerry van Dijk]

bill_@nospam wrote:

: It is kind'a hard to write Linux or Unix stuff in Ada, becuase the Posix
: Ada binding do not seem to work well or even documented. The Posix Ada
: bindings for linux (there is now even an RPM for these for Linux!) do not
: have an API document to tell one how to use them to write the sort of stuff
: you are talking about.

Unfortunately the documentation for the POSIX binding is the relevant IEEE
POSIX standard. This is unfortunate as this document can only be obtained
by buying it from the IEEE directly, for what I consider an unreasonable
amount of money (I could never justify it for myself, as a company it might
be different). Of course, the 1992 version seems to have disappeared, and
the current one is not yet finished.

Although I agree with Robert that a thin binding is usually much easier to
use if a) you already know your environment and b) already have some
documentation, I think that the current POSIX effort should be completed.
In a really friendly world, the standard would than be freely or at least
for an affordable price, be obtainable. Actually, the IEEE might even make
more money this way...

--
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: Linux Kernel in Ada. Repost

[Robert Dewar]

In article <FA0r38.6n@jvdsys.stuyts.nl>,
  jerry@jvdsys.stuyts.nl (Jerry van Dijk) wrote:

>  This is unfortunate as this document can only be
> obtained by buying it from the IEEE directly, for what I
> consider an unreasonable
> amount of money (I could never justify it for myself

Well hard to know what is unreasonable. These days,
typical text books cost $70, so the IEEE standard price
is not that out of line.

Of course I agree all standards should be freely
available, I think it is appalling that they are not,
and congratulations to Chris Anderson for managing the
hard negotations with ISO (at one point it was touch
and go whether there would be an ISO standard for Ada)
to ensure that at least the Ada standard is indeed
freely available.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Linux Kernel in Ada. Repost

[Aidan Skinner]

On Sun, 11 Apr 1999 16:33:53 GMT, Robert Dewar
<robert_dewar@my-dejanews.com> wrote:

>Well hard to know what is unreasonable. These days,
>typical text books cost $70, so the IEEE standard price
>is not that out of line.

hmm, that comes out at around 45 quid, about double the price of the 
haskell book i bought for my course and 50% more than the database
book (the most expensive one of the 6 or so I have). OTOH I live in
Glasgow, where people are generally poorer than average but also has
one of the highest literacy rates in the UK so this might be skewed
somewhat. Hell, the O'Reilly POSIX books for C doen't cost that much.

>Of course I agree all standards should be freely
>available, I think it is appalling that they are not,

Quite. Especially in these days when everybody and their CEO is trying
to be more Open. ;)

- Aidan (does Windows source code cause insanity when viewed? Find out
next time on Microsoft Beach) 
-- 
http://www.skinner.demon.co.uk/
http://www.gla.ac.uk/Clubs/WebSoc/~9704075s
"I could always suspend a few hundred accounts and watch what happens"

Re: Linux Kernel in Ada. Repost

[Robert Dewar]

In article <7emjk8$rp3@drn.newsguy.com>,
  bill_@nospam wrote:
> It is kind'a hard to write Linux or Unix stuff in Ada,
> becuase the Posix
> Ada binding do not seem to work well or even documented.
> The Posix Ada
> bindings for linux (there is now even an RPM for these
> for Linux!) do not
> have an API document to tell one how to use them to write
> the sort of stuff
> you are talking about.


First, of course there is documentation on how to use
the Posix interface, this is an IEEE standard, just as
for Ada you go to the RM, you go to the Posix standard
for details on the Ada binding to Posix.

Second, I see no particular reason to use these bindings.
Might as well call any services that you want directly. I
see no point in involving the Posix stuff here.

As for it being "kind'a hard to write .. Unix stuff [in
Ada]" that makes no sense, it is quite straightforward
in Ada to call any system services or other functions
that you need.

I am not at all clear that it is desirable to use something
as thick as the Posix bindings at the OS kernel level
anyway, that does not make any sense. The more reasonable
view of the Posix bindings is that they bind to the
kernel you are writing!

Of course if you were writing an OS from scratch, you might
consider using the IEEE Ada/Posix "binding" as the actual
API of the kernel, but that's another story completely.

In any case, the existing Posix interface is completely
irrelevant to this project. You are trying to write a
kernel in Ada, what on earth is the relevance of a binding
from Ada to the corresponding C kernel??

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Linux Kernel in Ada. Repost

[mike]

In article <7ep6uj$o97$1@nnrp1.dejanews.com>, Robert says...
>
>

>
>In article <7emjk8$rp3@drn.newsguy.com>,
>  bill_@nospam wrote:
>> It is kind'a hard to write Linux or Unix stuff in Ada,
>> becuase the Posix
>> Ada binding do not seem to work well or even documented.
>> The Posix Ada
>> bindings for linux (there is now even an RPM for these
>> for Linux!) do not
>> have an API document to tell one how to use them to write
>> the sort of stuff
>> you are talking about.
>


>
>First, of course there is documentation on how to use
>the Posix interface, this is an IEEE standard, just as
>for Ada you go to the RM, you go to the Posix standard
>for details on the Ada binding to Posix.
>

There is no free Ada/Posix binding document. one must buy it.
Something like $60 or $100 I hear? Do you know of a free one
we can download?

>Second, I see no particular reason to use these bindings.
>Might as well call any services that you want directly. I
>see no point in involving the Posix stuff here.
>
>As for it being "kind'a hard to write .. Unix stuff [in
>Ada]" that makes no sense, it is quite straightforward
>in Ada to call any system services or other functions
>that you need.
>

Some calls are easy, but some that takes in a pointer to 
some complicated C structure, might not be, you need to map
an Ada record to match the C struct correctly.
 
>I am not at all clear that it is desirable to use something
>as thick as the Posix bindings at the OS kernel level
>anyway, that does not make any sense. The more reasonable
>view of the Posix bindings is that they bind to the
>kernel you are writing!
>

But the above poster was responding to someone saying to write
Linux UTILTIES and Linux daemons type of applications in Ada, 
i.e. stuff that runs in user mode, not kernel mode. Inside the 
kernel, one does not make system calls.


>In any case, the existing Posix interface is completely
>irrelevant to this project. You are trying to write a
>kernel in Ada, 

Again, the repsonse was for the claim that writing Linux system type
utilities in Ada was easy. (not to write the kernel itself).

For example, If I want to write a system resource monitoring utility
for Linux. Most of the time, the application will be making C system
service calls to the system, and  making heavy use of Linux defined
C structs that contains such information. 

Just an example, making a stat() call, will require one to pass in such
a struct (define in sys/stat.h )
 
              struct stat
              {
                  dev_t         st_dev;      /* device */
                  ino_t         st_ino;      /* inode */
                  mode_t        st_mode;     /* protection */
                  nlink_t       st_nlink;    /* number of hard links */
                  uid_t         st_uid;      /* user ID of owner */
                  gid_t         st_gid;      /* group ID of owner */
                  dev_t         st_rdev;     /* device type (if inode device) */
                  off_t         st_size;     /* total size, in bytes */
                  unsigned long st_blksize;  /* blocksize for filesystem I/O */
                  unsigned long st_blocks;   /* number of blocks allocated */
                  time_t        st_atime;    /* time of last access */
                  time_t        st_mtime;    /* time of last modification */
                  time_t        st_ctime;    /* time of last change */
              };

Now, an Ada application that needs to call stat(), will have to pass
a pointer to a piece of memory that maps to the above layout. I have
to figure how to make my Ada record to be same size as above, with
correct field sizes.  I have to figure the size of each field, etc..

There are zillion (well, many) other such C structs, and 
many constants defined in those C header files, used. All of these 
need to have Ada equivelent.

This is a waste of time for me having to do this everytime I encounter
a new struct, and having each Ada programmer do the same becuase there
is no common Ada/Posix binding to use that allready did all this 
work for us.
 
>what on earth is the relevance of a binding
>from Ada to the corresponding C kernel??
>

I agree. If one is writing the kernel in Ada, offocurse the Posix
binding is not needed. But the posix binding is helpfull to write
user level Unix applications in Ada. (then one will need a C binding
to the Ada kernel. This sounds so nice!)

Lets face it, it is so much easier to write all of this Unix stuff 
in C than in Ada, unless a fully Ada working Unix binding exist 
to make it easier for programmers to use Ada on Unix/Linux, C will 
remain the prefered language of use on Unix for developing system 
applications.
 
Mike

Re: Linux Kernel in Ada. Repost

[Robert Dewar]

In article <7ep9p3$9fm@drn.newsguy.com>,
  mike@nospam wrote:
> There is no free Ada/Posix binding document.
> one must buy it
> Something like $60 or $100 I hear? Do you know of a free
> one we can download?

Probably not .. most standards cost money. The fact that
there is a free version of the Ada standard available
is very unusual (and took a big fight). Note that the
freely available version of the Ada standard is not quite
the same as the official standard, it contains paragraph
numbers, which are not allowed in ISO standards :-)

> Some calls are easy, but some that takes in a pointer to
> some complicated C structure, might not be, you need to
> map an Ada record to match the C struct correctly.

That's typically very straightforward using pragma
Convention, and pragma Unchecked_Union.
> There are zillion (well, many) other such C structs, and
> many constants defined in those C header files, used. All
> of these need to have Ada equivelent.

Which is why tools like c2ada are useful ...
>
> This is a waste of time for me having to do this
> everytime I encounter a new struct, and having each Ada
> programmer do the same becuase there is no common
> Ada/Posix binding to use that allready did all this
> work for us.

Well first of all, if you are talking about the IEEE
standard binding, there most certainly is a common
binding.

If you are talking about a comprehensive thin binding,
so far we have seen no demand for such a thing, which
is why it does not exist, at least in the GNAT world.
If someone wants to volunteer to create this, great!

What people want to do typically is to interface to
either rather standard stuff, some of which is available
for example in GNAT.OS_Lib, or Interfaces.C.Streams (the
former tend to be thick, the latter very thin), and some
of which they spin themselves as needed (a typical Ada
program does not make calls to huge numbers of C
routines).

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Linux Kernel in Ada. Repost

[Samuel Mize]

Robert Dewar <robert_dewar@my-dejanews.com> wrote:
> In article <7ep9p3$9fm@drn.newsguy.com>,
>   mike@nospam wrote:
...
>> This is a waste of time for me having to do this
>> everytime I encounter a new struct, and having each Ada
>> programmer do the same becuase there is no common
>> Ada/Posix binding to use that allready did all this
>> work for us.
> 
> Well first of all, if you are talking about the IEEE
> standard binding, there most certainly is a common
> binding.
> 
> If you are talking about a comprehensive thin binding,
> so far we have seen no demand for such a thing, which
> is why it does not exist, at least in the GNAT world.
> If someone wants to volunteer to create this, great!

And this brings the discussion around full circle.  There isn't much
work being done on extending Linux with Ada, because it requires a
thin binding, which doesn't exist because there's so little demand --
because there isn't much work being done on extending Linux with Ada!

ACT's business plan aims them in a different direction -- they won't
be the ones to break this cycle.

Fortunately, it shouldn't take a big, costly effort.  Someone could
set up a web site, and guide the architecture of the thin binding.

You want it set up so that it ports to a new OS by changing a couple
of key packages that everything else depends on (one of the few times
it's good for everything to "with" in a "global types" package).

You might also want to set up a standardized tool to extract the
critical constants from the C headers and generate the Ada packages
to define them.

Robert Dewar has rightly pointed out the level of coordination,
negotiation and consensus-building that it would require to create a
thin binding as a true standard -- that is, a standard agreed to by
such accrediting organizations as ISO and ANSI.

But a good de facto standard for a thin Linux/Posix/Unix binding may
do a lot to enhance Ada's market penetration.

I hope the original poster, or one of the other interested parties,
has the time and inclination to do this.  I think it could do a lot
of good.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Linux Kernel in Ada. Repost

[Robert Dewar]

In article <7et6j7$1qlr@news1.newsguy.com>,
  Samuel Mize <smize@imagin.net> wrote:
> And this brings the discussion around full circle.  There
> isn't much work being done on extending Linux with Ada,
> because it requires a thin binding,

To claim that this is the one and only, or even a
significant reason is simply not something you can
prove, or even reasonably argue in my view.

The Ada history is littered with sequences that go like
this.

1) Ada will wildly succeed if only someone does X
2) Someone does X
3) Ada does not wildly succeed

But instead of learning something, we just repeat the
sequence:

1) Ada will wildly succeed if only someone does Y
...

The trouble is in such scenarios is that step 1) is usually
just someones blind assertion of faith, with no real study
or evidence before moving on to step 2).

The fact of the matter is that it is entirely possible to
create useful tools for Linux, and to extend the
functionality of the kernel for that matter.

All it takes is (what will Dewar's magic number 1) be
.
.
.
.
.
.
.
.
.
.
.
.
.
work!


and there is no way around this. Thin bindings nor any
other magic bullet will not get around this fundamental
issue!

Robert Dewar






-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Linux Kernel in Ada. Repost

[Samuel Mize]

Robert Dewar <robert_dewar@my-dejanews.com> wrote:
> In article <7et6j7$1qlr@news1.newsguy.com>,
>   Samuel Mize <smize@imagin.net> wrote:
>> And this brings the discussion around full circle.  There
>> isn't much work being done on extending Linux with Ada,
>> because it requires a thin binding,
> 
> To claim that this is the one and only, or even a
> significant reason is simply not something you can
> prove, or even reasonably argue in my view.

Sorry if I was unclear.  I was summarizing other folks' points
on the way to my own conclusion.

I agree that this is not the ONLY deterrent, or indeed much of
a deterrent to serious commercial development.

I meant to refer to "amateur" work, in the best sense of that
word: something done for the love of it.

It seems reasonable that the lack of a common binding would be
a deterrent to starting such work in Ada.  One must learn how
to write a binding, analyze the OS, and write a partial binding,
before starting on the task one actually wanted to do.  Or, one
can use C and start on the fun stuff today!  Hmm, looks like C
is the language of choice.   ;-)  *

   * smiley added for the irony/sarcasm-impaired

Also, a shared binding will encourage people to share code
snippets and subroutines.  Without it, you may have to include
and maintain several bindings in one program to do so.

My own major point is:

  Linux utilities would be a more inviting arena for amateur
  work if there were a common foundation, starting with an
  agreed-to thin binding, maintained somewhere central.

  It would be especially inviting if this "somewhere" included
  a repository for sharing work, building on prior work, and
  coordinating shared work.

It's not a big focus in my professional life at this moment, but
if someone wants to pursue working in Linux utilities or kernel
extension, I'd recommend publishing a thin binding for shared
work as an early step.


> The Ada history is littered with sequences that go like
> this.
> 
> 1) Ada will wildly succeed if only someone does X
> 2) Someone does X
> 3) Ada does not wildly succeed

Again, if I was unclear, sorry.  I didn't intend to say that Ada
would succeed if only there were a thin binding to Linux/Posix.
(Or, indeed, that Ada would succeed only if there were one.)

I intended to say that a shared binding would encourage work on
Linux/Posix tools, especially at the amateur level.

I think it's fair to say that the absence of such a shared binding
discourages such work to some extent.


> The fact of the matter is that it is entirely possible to
> create useful tools for Linux, and to extend the
> functionality of the kernel for that matter.
> 
> All it takes is
...
> work!

Sure.  It would be an encouraging step if the people with interest
in this area were to SHARE some of the basic work.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Accessing C macro constants from Ada95

[Markus Kuhn]

Robert Dewar <robert_dewar@my-dejanews.com> writes:
|> First, of course there is documentation on how to use
|> the Posix interface, this is an IEEE standard, just as
|> for Ada you go to the RM, you go to the Posix standard
|> for details on the Ada binding to Posix.

Well, for those poor students who can't afford to buy the final
expensive document, there are even various inofficial drafts
floating arround. One was recently seen for instance briefly on
<http://www.cl.cam.ac.uk/~mgk25/volatile/> ...

|> Second, I see no particular reason to use these bindings.

|> As for it being "kind'a hard to write .. Unix stuff [in
|> Ada]" that makes no sense, it is quite straightforward
|> in Ada to call any system services or other functions
|> that you need.

Calling C library function from Ada95 sucks in one very
significant way: The authors of the C Interface annex of the
Ada95 standard have completely forgotten to generate a facility
for accessing C macro constants. What would be necessary is that every
Ada95 compiler that implements a C interface contains a complete
ISO C macro preprocessor. An import pragma would then allow to extract
an arbitrary numeric constant from any specifyable *.h file and
could then be used as an Ada constant.

Ada does indeed have nice facilities to access functions and variables
in C object files, but what has been completely forgotten is that
under C, traditionally a very significant part of the API comes
in the form of numeric macro constants defined in *.h files. And
Ada95 does not provide a portable way to get at these. Ada
programmers should not have to write buggy and dangerous Perl
hacks again and again to get access to the constants in C header
files. That I think is the main reason why people are interested
in POSIX.5, which provides all the necessary constants at least
for this important API.

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Accessing C macro constants from Ada95

[Jerry van Dijk]

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

: Calling C library function from Ada95 sucks in one very
: significant way: The authors of the C Interface annex of the
: Ada95 standard have completely forgotten to generate a facility
: for accessing C macro constants. What would be necessary is that every
: Ada95 compiler that implements a C interface contains a complete
: ISO C macro preprocessor.

The question, of course, is: macro constants are only a small portion of
the macro's that are defined in header files. What should such a pre-processor
do with all the macro functions that can go several levels deep and imbed a
lot of function call's ?

A tool like c2ada seems to be a much more useful solution.

As for constant definition conversion, I usualy do this with a simple
editor macro.

--
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: Accessing C macro constants from Ada95

[Robert Dewar]

In article <7eqoj2$r27$1@pegasus.csx.cam.ac.uk>,
  mgk25@cl.cam.ac.uk (Markus Kuhn) wrote:
> That I think is the main reason why people are interested
> in POSIX.5, which provides all the necessary constants at
> least for this important API.

Sure, and people are definitely interested in POSIX.5,
which is why we put effort into implementing it, and indeed
so far there is no demand from customers for a thin binding
to corresponding stuff except in limited cases (e.g.
sockets).

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Accessing C macro constants from Ada95

[Robert Dewar]

In article <7eqoj2$r27$1@pegasus.csx.cam.ac.uk>,
  mgk25@cl.cam.ac.uk (Markus Kuhn) wrote:
> Ada does indeed have nice facilities to access functions
> and variables in C object files, but what has been
> completely forgotten is that
> under C, traditionally a very significant part of the API
> comes in the form of numeric macro constants defined in
> *.h files.

This was most certainly not "forgotten" ...

> What would be necessary is that every
> Ada95 compiler that implements a C interface contains a
complete
> ISO C macro preprocessor. An import pragma would then
allow to extract
> an arbitrary numeric constant from any specifyable *.h
file and
> could then be used as an Ada constant.

This is so impractical that I can't tell if you are really
serious. In
any case you do a good job of indicating why there is no
automatic
feature for importing such constants!

> And Ada95 does not provide a portable way to get at
> these.

You mean apart from defining them, copying the constants
(no different in principle from copying the parameters
when you pragma Import something ....)

> Ada programmers should not have to write buggy and
> dangerous Perl hacks again and again to get access to the
> constants in C header files.

I don't think they should do this even once, I certainly
never have, and have accessed such constants many times.

Basically, when importing functions or constants, we have
two ways
of doing things.

We either look at the header, and manually acquire the
functions and
their parameters, and any constant values needed, and write
the
necessary declarations in our Ada program manually.

Or we use a program like c2ada, or the SGI binding
generator that reads
a header and automaticlly extracts this information.

I do not see the big deal here!

If you have a situation where the constants can change and
you do not
want to have to modify the Ada accordingly, then it is easy
enough (again
manually or automatically) to write simple C functions that
"cloak" the
constants.

I must say I have never found this to be a significant
difficulty.

On the other hand, trying to pursue the language extension
suggestion
that Markus makes sounds deadly to me. Just imagine the
amount of
material that would be required for a stand alone
definition of exactly
what this Import pragma would do, UGH!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Accessing C macro constants from Ada95

[Markus Kuhn]

In Robert Dewar <robert_dewar@my-dejanews.com> writes:
|> Note incidentally that there is nothing to stop a given
|> compiler from implementing:
|> 
|>    X : constant Int;
|>    pragma Import (C, X, "header.h/X");

Yes, that is exactly what I was thinking about. This would simplify the
fully automatic, portable, and comfortable generation of thin C bindings
significantly.

|> On the other hand, trying to pursue the language extension suggestion
|> that Markus makes sounds deadly to me. Just imagine the amount of
|> material that would be required for a stand alone definition of exactly
|> what this Import pragma would do, UGH!

I really do not see the big difficulty here. The specification of this
Ada pragma for importing constants from the C preprocessor macros could
just reference the ISO C standard to get all the required semantics
and terminology readily specified there. Similarly, in an implementation,
compilers like GNAT do already have a full C preprocessor built in,
because they also happen to be full C compilers, so just use the
existing C mechanics to process the *.h files.

I am fully aware of all the existing hacks including c2ada,
writing C wrappers that export macros as C variables, and the option
of copying things manually. Sure, all this is possible, but it is
miles away from what I normally call "portable programming".
Ada alone is a good language for comfortable portable programming,
and so is C alone. However bindings from C to Ada suddenly require
loads of awkward hacks and/or manual intervention that I would
never like to have to explain to students familiar with C in
an Ada programming beginner's class.

You have shown to be a big fan of thin bindings, and I do agree
with you. However I am a bit disappointed about the bureaucratic
effort I have to go through to actually generate a thin C binding,
considering that such a thin binding by definition doesn't add any
functionality or abstraction (otherwise we would call it a thick
binding). I even wonder, why Ada compilers can't generate the equivalent
of thin C bindings fully automatically after I simply name the relevant
C objects that I want to import? Why is it necessary to write wrapper
functions, use tools like c2ada, etc. if all the necessary type
and naming information is practically already available in the C header
files?

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Accessing C macro constants from Ada95

[Robert Dewar]

In article <7ev36j$34t$1@pegasus.csx.cam.ac.uk>,
  mgk25@cl.cam.ac.uk (Markus Kuhn) wrote:
> In Robert Dewar <robert_dewar@my-dejanews.com> writes:
> |> Note incidentally that there is nothing to stop a
given
> |> compiler from implementing:
> |>
> |>    X : constant Int;
> |>    pragma Import (C, X, "header.h/X");
>
> Yes, that is exactly what I was thinking about. This
> would simplify the fully automatic, portable, and
> comfortable generation of thin C bindings
> significantly.

To me, this seems a very minor issue, since it can
perfectly well be done by a competent binding generator
tool, what does it matter whether the tool generates a
pragma Import of the above form, or an appropriate constant
definition (obviously the latter is preferable, since it
would be a static constant, making the former static is
problematic).

> I really do not see the big difficulty here. The
> specification of this Ada pragma for importing constants
> from the C preprocessor macros could just reference the
> ISO C standard to get all the required semantics
> and terminology readily specified there.

Not by a long shot, this would be VERY difficult to do. The
C preprocessor is a completely unrestricted macro
processor, and obviously arbitrary macros cannot be
handled. Specifying what could and what could not be
handled could not be done simply by reference to the C
standard (by the way, is the C standard freely available?
that would be an absolute requirement even if it were
practical).

> Similarly, in an implementation, compilers like GNAT do
> already have a full C preprocessor built in, because they
> also happen to be full C compilers, so just use the
> existing C mechanics to process the *.h files.

No, that won't help. If you preprocess a header file, you
lose the semantic information of what is going on, in
particular the disapearence of macro names will obscure
things within a given header.

For example, if we have

  #define LOWPRIO  10
  #define HIGHPRIO 52
  #define DEFPRIO ((LOWPRIO + HIGHPRO)/2)

The best Ada translation, and one that is well within reach
of a reasonably coded binding generator is

    LOWPRIO  : constant := 10;
    HIGHPRIO : constant := 52;
    DEFPRIO  : constant := (LOWPRIO + HIGHPRIO) / 2;

but if you work from the preprocessed header file, you
can't do that. What is needed is juggling the input and
output of the preprocessor.

The rules for importation of constants would be very
delicate, in particular, understanding what would and
would not be static would be a real mess.

What you are really trying to reach for here is trying to
define the semantics of a particular binding generator
approach into the Ada standard. This would have been a
very bad idea, since we just don't know enough yet to know
how to do this. Standardizing things you do not understand
is a mistake.

People without experience in language design often draw,
often with a big brush, a picture of a general facility
that they would like to have, and it is obvious to them
that it is needed. Unfortunately the phrase "The Devil
is in the Details" might well have been invented for this
field, and any attempt to develop Marcus' proposal in a
general direction suitable for standardization would be
bound to fail in my opinion.

A given implementation could do a limited job, and indeed
it would be an interesting (and not totally unreasonably
difficult) project to try to put some capability like this
into GNAT.

This is not a direction that ACT sees as technically
sound however. We think it makes FAR more sense to try
to develop freely available binding tool generation
technology. The currently available C2Ada is very limited,
and it is here that we can really get something happening.

For one thing, we see little future in a binding tool that
can only handle C, it is clearly essential to be able to
handle C++ and Java as well, and that is the starting point
for our work in this area.

Robert Dewar
Ada Core Technologies

(I added the formal signature because of the peek into our
future plays in the last couple of paragraphs :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Accessing C macro constants from Ada95

[dennison]

In article <7ev9ft$n9m$1@nnrp1.dejanews.com>,
  Robert Dewar <robert_dewar@my-dejanews.com> wrote:

> For one thing, we see little future in a binding tool that
> can only handle C, it is clearly essential to be able to
> handle C++ and Java as well, and that is the starting point
> for our work in this area.

But would that make sense in *one* tool? How often am I going to want to
convert C++ and Java at the same time? I don't see a lot of overlapping
functionality either, unless they can use a common "back end".

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Accessing C macro constants from Ada95

[Aidan Skinner]

On 11 Apr 1999 18:10:42 GMT, Markus Kuhn <mgk25@cl.cam.ac.uk> wrote:

>Calling C library function from Ada95 sucks in one very
>significant way: The authors of the C Interface annex of the
>Ada95 standard have completely forgotten to generate a facility
>for accessing C macro constants. What would be necessary is that every

The way I (work around|hack) this is to run c2ada over the .h file and
then get only the functions I'm interested in bound properly in the
resulting .ad[bs].

OTOH this is very definately a hack (although it does mean you have
the start of a proper binding to whatever) and something that should have
been considered in the language design process. :(

- Aidan

-- 
http://www.skinner.demon.co.uk/
http://www.gla.ac.uk/Clubs/WebSoc/~9704075s
"I could always suspend a few hundred accounts and watch what happens"

Re: Accessing C macro constants from Ada95

[Robert Dewar]

In article <slrn7h41up.1cm.aidan@skinner.demon.co.uk>,
  aidan@skinner.demon.co.uk (Aidan Skinner) wrote:
> OTOH this is very definately a hack (although it does
> mean you have the start of a proper binding to whatever)
> and something that should have
> been considered in the language design process. :(

What makes you think it wasn't?

Just because you don't see a solution to the problem
you have in mind does not mean it was not considered.

The current definitions in the RM for interface to C are
what we decided were the appropriate level, and note that
even most of these are implementation advice, rather than
requirements, because it is VERY difficult to fashion
requirements in this area, due to the huge variance in
C compiler technologies with which one might want to
interface.

In fact binding generators like C2Ada (or the much more
powerful SGI binding generator) are *exactly* the kind of
tools that were envisioned during the design process as
being *the* appropriate way to solve this problem.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Accessing C macro constants from Ada95

[Robert Dewar]

In article <7eqoj2$r27$1@pegasus.csx.cam.ac.uk>,
  mgk25@cl.cam.ac.uk (Markus Kuhn) wrote:

> Ada does indeed have nice facilities to access functions
> and variables in C object files, but what has been
> completely forgotten is that
> under C, traditionally a very significant part of the API
> comes in the form of numeric macro constants defined in
> *.h files.

Note incidentally that there is nothing to stop a given
compiler from implementing:

   x : constant Int;
   pragma Import (C, X, "header.h/X");

or somesuch, but I see no practical way at all to
standardize such a beast as part of the Ada standard.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Accessing C macro constants from Ada95

[Tarjei Tj�stheim Jensen]

Markus Kuhn wrote :
>Ada does indeed have nice facilities to access functions and variables
>in C object files, but what has been completely forgotten is that
>under C, traditionally a very significant part of the API comes
>in the form of numeric macro constants defined in *.h files. And
>Ada95 does not provide a portable way to get at these. Ada
>programmers should not have to write buggy and dangerous Perl
>hacks again and again to get access to the constants in C header
>files. That I think is the main reason why people are interested
>in POSIX.5, which provides all the necessary constants at least
>for this important API.


In order to do this you would need to implement a complete C preprocessor and
probably parts of the compiler as well.

 It is completely unpractical compared to writing a C program that generates
the apropriate module(s) or perhaps one should link the Ada program with a C
module that provides the answers.


Greetings,

Re: Linux Kernel in Ada. Repost

[Robert Dewar]

In article <370CC730.4C6112DB@utech.net>,
  "Jeffrey D. Cherry" <jdcherry@utech.net> wrote:
> I'd be interested ... sounds like fun.  I'm not sure
> about the C2Ada tool since I have no experience with it
> myself.

Even if C2Ada were a fully capable C-to-Ada translator,
which it is not, it would be totally useless for this
project.

I cannot imagine a worse excercise than to reproduce the
Linux Kernel in C-style Ada.

If people want to do this, the challenge is to redesign
at all levels of abstraction in elegant Ada style. A tool
for automatic translation just gets in the way of this
goal.

Note that if you use GNAT here, you have extremely easy
integration with gcc-C which is of course what Linux uses.
You don't have to rewrite the entire kernel.

Instead, just take some sample modules and really work hard
on those to demonstrate the advantages of Ada style.

Then you can demonstrate that your code works by mixing it
in with the C code for other parts of the kernel.
Eventually of course you might replace more, most, or all
of the C code.

But the point is that this is then a nice incremental
project with a working system at every stage of the game,
which can be a nice demonstration of Ada right away.

Don't just think of a project like this as being aimed at
showing that Linux can be written in Ada, of course it can.
Anything can be written in any language, and it proves
nothing.

The goal is to show examples that back up the claim of
Ada being preferable to C for this kind of programming.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Linux Kernel in Ada. Repost

[Bruce MacDonald]

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

Although I hate people who don�t edit down the post that they are responding
to, the signal to noise ratio is so high in Dr. Dewar�s note that I have to
let it all stand.

I agree that �C style� Ada is anathema. I had planned to translate and then
rewrite. I hadn�t even considered the �mixed C and Ada� incremental approach
you mention. This, of course, is the �right� approach. (It is the
embarrassment of missing the obvious that keeps me lurking in cla instead of
participating.)

The goal of the project is not to prove that Ada is �better� than C. I fear
those in need of more proof will never accept it. That some people writing
software do not accept the idea of letting the computer do most of the work
for you (by pointing out your errors) is a bad omen.

The goal is not to unseat Bill Gates or Linus Torvolds; they do what they do
very well.

The goal of the project is to save the instructor, of the introductory OS
course that will use the kernel, the hassle of debugging student C (a
superset of ANSI C) when what he or she wants to do is teach operating system
principles.

Bruce MacDonald


In article <7ep6kp$nv3$1@nnrp1.dejanews.com>,
  Robert Dewar <robert_dewar@my-dejanews.com> wrote:

> Even if C2Ada were a fully capable C-to-Ada translator,
> which it is not, it would be totally useless for this
> project.
>
> I cannot imagine a worse excercise than to reproduce the
> Linux Kernel in C-style Ada.
>
> If people want to do this, the challenge is to redesign
> at all levels of abstraction in elegant Ada style. A tool
> for automatic translation just gets in the way of this
> goal.
>
> Note that if you use GNAT here, you have extremely easy
> integration with gcc-C which is of course what Linux uses.
> You don't have to rewrite the entire kernel.
>
> Instead, just take some sample modules and really work hard
> on those to demonstrate the advantages of Ada style.
>
> Then you can demonstrate that your code works by mixing it
> in with the C code for other parts of the kernel.
> Eventually of course you might replace more, most, or all
> of the C code.
>
> But the point is that this is then a nice incremental
> project with a working system at every stage of the game,
> which can be a nice demonstration of Ada right away.
>
> Don't just think of a project like this as being aimed at
> showing that Linux can be written in Ada, of course it can.
> Anything can be written in any language, and it proves
> nothing.
>
> The goal is to show examples that back up the claim of
> Ada being preferable to C for this kind of programming.
>
> Robert Dewar


What doesn't kill you, makes you bitter and cynical.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Linux Kernel in Ada. Repost

[Buz Cory]

In article <7eg43i$d3b$1@nnrp1.dejanews.com>,
  Bruce MacDonald <microbards@my-dejanews.com> wrote:
> I have been casting about trying to find out if anyone is rewriting the Linux
> kernel in a high level language, such as Ada.

I am *extremely* interested in such a project. In fact I even mentioned
it to the ELKS group about a year and a half ago, drawing a lot of
flames for my trouble and not much else.

However, in the followups to this original post, there was no mention of
any such existing project nor of actually *doing* anything!

> Is anyone else interested in a project like this?

If you are interested in *working* on such a project (either in coding,
managing, contributing to overall design, doing research for/in existing
documentation, writing docs, etc) please send me email (not posts to
this thread). I will collect the names and addresses and periodically
send the entire list to those that are on it (only). Updates about a
week after a name is received that is not already on the list seems
about right.

I might even be able to start a mailing list (or a WWW forum, or both)
for the members of such a project.

[snip re: intermetrics c2ada]

May the Power of a REAL OS be with us all,
==Buz

--
Buz Cory of Buzco Systems -- New York NY USA http://buzco.ddns.org/
write to <helpdesk@buzco.ddns.org> for FREE help with:
    Getting started with the Ada Programming Language.
Ada 95 is here! Why use an archaic, bug-prone language?:
--
Note: The above mailing address is expected to be good for about a year from
this date but probably not much more.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Linux Kernel in Ada. Repost

[Hans N. Beck]

High,

Buz Cory schrieb:

> In article <7eg43i$d3b$1@nnrp1.dejanews.com>,
>   Bruce MacDonald <microbards@my-dejanews.com> wrote:
> > I have been casting about trying to find out if anyone is rewriting the Linux
> > kernel in a high level language, such as Ada.
>
> I am *extremely* interested in such a project. In fact I even mentioned
> it to the ELKS group about a year and a half ago, drawing a lot of
> flames for my trouble and not much else.
>
> However, in the followups to this original post, there was no mention of
> any such existing project nor of actually *doing* anything!
>
> > Is anyone else interested in a project like this?
>
> If you are interested in *working* on such a project (either in coding,
> managing, contributing to overall design, doing research for/in existing
> documentation, writing docs, etc) please send me email (not posts to
> this thread). I will collect the names and addresses and periodically
> send the entire list to those that are on it (only). Updates about a
> week after a name is received that is not already on the list seems
> about right.
>

sorry, I've lost the focus on the discussion. Do you want to create aexactly copy
of the linux we now have, or would you develop some kind
of new ("modern") kernel with linux (posix) shell above ?

Hans
--
            Dipl.-Ing. Hans N. Beck
 --------------------------------------------
  Technischer + didaktischer Computereinsatz
 --------------------------------------------
        Waldstr. 28, D-75045 Walzbachtal

        \   Tel: +49 (0)7203 922280   /
         \  Fax: +49 (0)7203 922281  /
          \ Handy:    0177 5383233  /

           eMail: hnbeck@t-online.de