public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>
To: gcc@gcc.gnu.org
Subject: [RFC] Linux system call builtins
Date: Tue, 09 Apr 2024 23:19:16 -0300	[thread overview]
Message-ID: <6a50378aee7b82c8d0769a631b398d09@gmail.com> (raw)
In-Reply-To: <941dc5f2-b524-4cd0-a518-ae2ffc9d2488@free.fr>

> I see systems making it more  difficult for code to make syscalls,
> not easier.

That's true.

I think it's because other systems can afford to keep that ABI unstable.
Since Linux is an independently developed kernel, it _must_ be possible
to target the kernel directly with no user space component in-between.
Someone might write a freestanding program with nothing but system calls
and boot Linux directly into it.

This feature also makes it ideal for other programming languages.
On every other operating system, you need to link to some C library.
On Linux, that library is not actually necessary due to stable ABIs.
Rust programmers could conceivably recreate the entire Linux userspace
in Rust given enough time and effort. I created a programming language
based entirely around that concept, a lisp variant which uses nothing
but system calls and provides a system-call primitive to lisp code.
It's still in its infancy due to my limited free time but it's a fact
that with system calls it could do anything, it could mount disks.

> I also think that this could be misleading.

I don't see how. The __builtin_ prefix makes it clear
that it's a compiler feature rather than a libc function.

> There are sometimes subtle differences between the
> syscall interface and the interface exported by libc.

Yes. The C libraries seem to have some kind of cancellation mechanism
built right into it, for example. Using the system calls directly
eliminates them. This lets other languages build their own mechanisms.

  reply	other threads:[~2024-04-10  2:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-08  9:19 Matheus Afonso Martins Moreira
2024-04-08  9:58 ` Jonathan Wakely
2024-04-08 11:59   ` Matheus Afonso Martins Moreira
2024-04-08 14:00     ` Jonathan Wakely
2024-04-08 11:24 ` Florian Weimer
2024-04-08 11:44   ` Alexander Monakov
2024-04-08 11:50     ` Florian Weimer
2024-04-08 13:01       ` Alexander Monakov
2024-04-08 13:37   ` Matheus Afonso Martins Moreira
2024-04-08 18:18 ` Paul Iannetta
2024-04-08 18:26   ` Andrew Pinski
2024-04-08 20:01     ` Paul Iannetta
2024-04-08 20:20       ` Paul Koning
2024-04-10  1:48     ` Matheus Afonso Martins Moreira
2024-04-10 13:15       ` Paul Koning
2024-04-10 14:10         ` Matheus Afonso Martins Moreira
2024-04-10  1:26   ` Matheus Afonso Martins Moreira
2024-04-08 20:24 ` Paul Floyd
2024-04-10  2:19   ` Matheus Afonso Martins Moreira [this message]
2024-04-09 11:45 ` Szabolcs Nagy
2024-04-10  2:59   ` Matheus Afonso Martins Moreira
2024-04-10 11:04     ` Szabolcs Nagy
2024-04-10 14:00       ` Matheus Afonso Martins Moreira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6a50378aee7b82c8d0769a631b398d09@gmail.com \
    --to=matheus.a.m.moreira@gmail.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).