public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: "Joachim Schmitz" <jojo@schmitz-digital.de>
Cc: <rsbecker@nexbridge.com>,  <libc-help@sourceware.org>,
	<mike_kilpatrick@nskopensource.com>,
	 "'Shiva Subramanian'" <shiva.subramanian@tcm.uk.com>,
	 "'Bill Honaker'" <bhonaker@xid.com>
Subject: Re: AW: Re-port Intent for HPE NonStop (a.k.a. Tandem)
Date: Mon, 14 Mar 2022 09:32:31 +0100	[thread overview]
Message-ID: <87czipylwg.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <003901d8377b$32ab1e90$98015bb0$@schmitz-digital.de> (Joachim Schmitz's message of "Mon, 14 Mar 2022 09:12:06 +0100")

* Joachim Schmitz:

> No idea whether that port had ever been send back upstream, it must have
> been done in 2007 or before.
> Not sure what you mean by "stable kernel interface"?

In general, Linux does not remove any interfaces for entering the kernel
once they have been added.  The system call numbers that identify the
entry points also does not change over time.  For example, on x86-64,
there is still a fstat system call, even though it has been superseded
by newfstatat first, and then by statx.

Other operating systems treat libc has the stable binary interface (if
they have one at all), and remove the old system calls from their
kernels once libc has been upgraded.  This means it is not feasible to
maintain libc as a separate project.

> No, sorry, unfortunately no gcc available nor possible to cross-compile, it
> is actually the assembler part that is missing IIRC

You will have to release that first, preferably as a new target for
binutils or LLVM, and then a compiler.  But again, even if you do all
that, it is unlikely that we would accept a glibc port.  But without the
toolchain, there is simply no way that it can happen.  I think glibc
stopped supporting proprietary toolchains some time in the 90s, before
the glibc 2.0 release, and we are definitely not going back.  Sorry.

If you need a glibc compatibility layer, maybe you should look at gnulib
instead.

Thanks,
Florian


  reply	other threads:[~2022-03-14  8:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-13 12:43 rsbecker
2022-03-14  7:54 ` Florian Weimer
2022-03-14  8:12   ` AW: " Joachim Schmitz
2022-03-14  8:32     ` Florian Weimer [this message]
2022-03-14  8:49       ` AW: " Joachim Schmitz
2022-03-14  8:55         ` Florian Weimer
2022-03-14 12:48   ` rsbecker
2022-03-14 13:12     ` Florian Weimer
2022-03-14 14:20       ` Adhemerval Zanella

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=87czipylwg.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=bhonaker@xid.com \
    --cc=jojo@schmitz-digital.de \
    --cc=libc-help@sourceware.org \
    --cc=mike_kilpatrick@nskopensource.com \
    --cc=rsbecker@nexbridge.com \
    --cc=shiva.subramanian@tcm.uk.com \
    /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).