From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:5353:: with SMTP id n80-v6mr1362891itb.6.1531422479417; Thu, 12 Jul 2018 12:07:59 -0700 (PDT) X-Received: by 2002:aca:c744:: with SMTP id x65-v6mr743265oif.2.1531422479212; Thu, 12 Jul 2018 12:07:59 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder4.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!g2-v6no1798603itf.0!news-out.google.com!l67-v6ni2053itl.0!nntp.google.com!d7-v6no1811524itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 12 Jul 2018 12:07:58 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <2048d6d6-04e2-4e2c-9483-e3769da59781@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Kernel Syscall from Ada? From: "Dan'l Miller" Injection-Date: Thu, 12 Jul 2018 19:07:59 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53780 Date: 2018-07-12T12:07:58-07:00 List-Id: On Thursday, June 23, 2016 at 5:18:14 PM UTC-5, Randy Brukardt wrote: > "Diogenes" wrote in message=20 > news:2048d6d6-04e2-4e2c-9483-e3769da59781@googlegroups.com... > >Is there a simple way to make a direct (Linux)Kernel syscall from Ada=20 > >without > >using the system C library? i.e. Make a direct call as in Assembler? >=20 > On almost all modern systems, a system call IS a call to some C subprogra= m.=20 > (On Windows, they're calls into a DLL; Linux appears similar although I'v= e=20 > never studied the details.) There's nothing like the set-registers and tr= ap=20 > like there was in the old days on MS-DOS, XENIX, and other systems. >=20 > So the only way to make a system call is via aspect Import to the needed = C=20 > routine. (On Windows, I''d expect that a program that didn't do any syste= m=20 > calls would be much smaller than a "normal" program; Windows needs some= =20 > stuff added to every program; it doesn't have anything to do with Ada=20 > per-se.) >=20 > Randy. One of the more succinct summaries of the legacy 8086, 32-bit x86, and 64-b= it x86-64: https://stackoverflow.com/questions/12806584/what-is-better-int-0x80-or-sys= call Randy is mostly accurate: interrupt 80=E2=82=81=E2=82=86 has faded into an= tiquity and currently everything about system calls boils down to C subprog= rams. Conversely, the syscall mechanism is best thought of as an =E2=80=A2assembl= y=E2=80=A2 subprogram (and calling convention) that crosses a ring boundary= whose syscall-table array of assembly subprograms does have some vague res= emblance to the old interrupt 80=E2=82=81=E2=82=86 vector table. (No proce= ssor manufacturer would hardcode C-language conventions into their silicon = for context switches between protection rings. It is all C out of habit, n= ot hardware-imposed necessity.) Conceivably Ada could present its own array of Ada subprograms in its own s= yscall-table, so that Ada would not come down to invoking C subprograms in = userspace. An Ada-centric new distribution of Linux (or BSD Unix or GNU Hu= rd or any other operating system, for that matter) would be needed to add a= n Ada-only syscall vector/lookup table (LUT) in addition to the current C-o= nly syscall LUT. But such a new distro of Ada-Linux (or Ada-BSD or Ada-Hur= d) could showcase 100%-Ada software in userspace, encourage Ada programming= in kernelspace, and use that Ada-based package manager announced recently = on c.l.a. lucid explanation of 32-bit sysenter: http://articles.manugarg.com/systemcallinlinux2_6.html a taste of VDSO to avoid a userspace-to-kernelspace context switch for some= would-be/has-been syscalls: https://en.wikipedia.org/wiki/VDSO the complexity of on which processors AMD syscall versus Intel sysenter ins= tructions are supported or not:=20 https://ReverseEngineering.stackexchange.com/questions/16454/struggling-bet= ween-syscall-or-sysenter-windows