[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 29 Jul 2018 11:49:53 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: musl "Linux-dependencies" info [was Re: Timeline for 1.1.20?]
On Sun, Jul 29, 2018 at 07:40:25AM -0400, Christopher Friedt wrote:
> On Sat, Jul 28, 2018 at 3:55 PM Rich Felker <dalias@...c.org> wrote:
> > Yes, but I don't know how to set it up, and any proper approach to
> > setting it up really shouldn't require the project maintainer to know
> > how, since it should revolve around a separate CI project pulling
> > musl, libc-test, and possibly other sources (e.g. mcm) as either
> > subrepos or part of the build scripts, then evaluating the resutls.
>
> I'll set up a .gitlab-ci.yml file - likely will use one 'pipelilne' to
> trigger other pipelines that exercise all combinations here:
>
> https://github.com/richfelker/musl-cross-make#supported-targets
>
> Speaking of which, one of my eventual use-cases is an rtos that uses
> the same syscall numbers as linux for each arch. Originally I was
> using bionic libc, but it's just difficult to maintain a permanent
> fork. Beyond syscall numbers, is there any specific reason that musl
> requires linux?
The other "Linux" interfaces it uses are parts of /proc (needed for
filling in gaps of some syscalls' functionality), some netlink
functionality (for network interface enumeration interfaces), and some
ioctls (for determining if something is a tty, some socket operations,
etc.).
There are also some de facto standard pathnames used for configuration
(resolv.conf, passwd, etc.) on top of the standard ones specified by
POSIX (/dev/null, etc.).
Some details are in the (incomplete, outdated, but IMO very good on
what it does have) musl documentation:
https://www.musl-libc.org/manual.html
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
