From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12278 Path: news.gmane.org!.POSTED!not-for-mail From: ardi Newsgroups: gmane.linux.lib.musl.general Subject: Re: Feature request: building musl in a portable way Date: Fri, 22 Dec 2017 20:04:31 +0100 Message-ID: References: <20171221213822.GY1627@brightrain.aerifal.cx> <20171222164339.GB1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1513969371 17816 195.159.176.226 (22 Dec 2017 19:02:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Dec 2017 19:02:51 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12294-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 22 20:02:47 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eSSaj-0004DQ-96 for gllmg-musl@m.gmane.org; Fri, 22 Dec 2017 20:02:45 +0100 Original-Received: (qmail 23720 invoked by uid 550); 22 Dec 2017 19:04:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 23699 invoked from network); 22 Dec 2017 19:04:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=WM4cS7HXfi3KZKkelTc2DGLxlyvMDf295fw47EI/XuU=; b=XlNJGABNgZBjcY9rwuQiEyHzdOxl/OuKLpq6mKRzJMBhLp+JbMTEkSh6pTVOmFgI1H 2mkPJmbD36rnqO62qx8dHaiwjmavk/I3IIn6f4NSNk3qWn5f9yRUpFUQS2N3udvy9l+P dfRlnxVWB6+OvRdpRsyTPo2SN4ybns5FNYAFKQL0XXEon0Nd881/VH1dot6DZqV74zXU qdFZEsOFCRNTAb9Cqa46x1khICvJkwKFhJMNz1w8eC3dF9jGmLLvLjnpVViIaFDJlReY dKYPV/H6KbL3Fj/D3ndK9QTPuG5NJt0r0zLFpZ88OOGzXubvhbSHAyGlhVADFUjQYbZO 1q5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=WM4cS7HXfi3KZKkelTc2DGLxlyvMDf295fw47EI/XuU=; b=d47vj/hcwytcwbm2vecfi73WE0ugs/0VYESIwrYwLvdhMUkgO4cMS3mqFRggOfchtP v/LO4hNY7K2W0EWYSZbxBfLpiKX+Yst9Pqu7Iz1MklLnYBzRVWkFYHHVNoP3/fDXOa7S n41+g2X7IGV/d2/J+wsTZgkzA3qGGWmzd7LYN++Fe8j+CPH6Fx2l5SO18nHhKm9cqAgf HC8K+aUU56UTiA/xGT1owSKQ39qPft65XHqApkk2LaWi+B2viJCbHtUP+/PNQdYcgjQ8 uUoY0oACUP8SpCTFnez/qfPDDUIy5ryItKD6C+hdLtC0lrudH/zkUyHS8qLA93gdT90I o6Xw== X-Gm-Message-State: AKGB3mJ0wAd35tEfbHvFAylIlxkbp9lus1wuECzZchPuQh1Shb1EI3bC IUAvJR4RcUBx3/TFGBuoulpFMrx18cVl9lia4Ws= X-Google-Smtp-Source: ACJfBossEy+v/e/29ByWHJ6Kfp617Bmg4aXpadauYKpy4gZ2hBRT3tmxtrcRVX1RON0YHPwHgR7GCh7/TZ4EXITgL2I= X-Received: by 10.99.64.199 with SMTP id n190mr13146747pga.296.1513969472438; Fri, 22 Dec 2017 11:04:32 -0800 (PST) In-Reply-To: <20171222164339.GB1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12278 Archived-At: On Fri, Dec 22, 2017 at 5:43 PM, Rich Felker wrote: > [...] You can change the syscall layer just by > making a new arch that defines (in syscall_arch.h and bits/syscall.h) > your mechanism. See the recent wasm thread or midipix for examples of > more exotic ways this can be done. Thanks a lot!! I'll try to follow this path. It looks clean. > But be aware that the ability to > get a POSIX-conforming implementation where EINTR and thread > cancellation work requires some sort of atomic boundary that > determines when a syscall has passed the point of having successful > side effects, which makes implementing the syscalls just as functions > hard. I'm not sure if I can hit this scenario but I'll research this. Thanks! > Stepping back a bit, I suspect what you want is to just be able to > implement functions like open(), read(), etc. on your own instead of > implement something like actual syscalls, based on a notion that > open(), read(), etc. "are the syscalls". Not based on that notion, but thinking that the number of functions issuing syscalls would be reduced, and substituting such functions would be less work than translating syscalls. But the approach you suggested above is better. > [...] > As long as you do it the way that acknowledges the above, the "heavy > editing" is isolated to the arch directories you add. That's really what I want! > [...] > There are indeed a small number of places where workarounds or other > considerations for Linux-specific parts of the syscall interface > boundary are in general source files rather than in the syscall glue > layer, but I think the number is quite small. If there are > particularly egregious ones that you think could be improved upon, > please let me know. Yes, I believe that whenever there are assembly source files in some directory in the musl tree, there're functions there that make syscalls without going through the interface you defined above. I'll look at this and I'll see if it can be improved somehow. Thanks a lot! ardi