This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 10/15] RISC-V: Linux Syscall Interface
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Christoph Hellwig <hch at lst dot de>, Joseph Myers <joseph at codesourcery dot com>
- Cc: Palmer Dabbelt <palmer at dabbelt dot com>, libc-alpha at sourceware dot org, Andrew Waterman <andrew at sifive dot com>, Darius Rad <darius at bluespec dot com>, dj at redhat dot com
- Date: Wed, 3 Jan 2018 13:56:32 -0200
- Subject: Re: [PATCH v2 10/15] RISC-V: Linux Syscall Interface
- Authentication-results: sourceware.org; auth=none
- References: <mhng-a9f80547-ccbd-43a4-89d9-9ee8d1e6d067@palmer-si-x1c4> <alpine.DEB.2.20.1801010052240.28505@digraph.polyomino.org.uk> <20180103134339.GB14077@lst.de>
On 03/01/2018 11:43, Christoph Hellwig wrote:
> On Mon, Jan 01, 2018 at 12:56:14AM +0000, Joseph Myers wrote:
>> such case, whether a copy from another architecture or a #include from
>> another architecture, indicates a case where refactoring is needed to
>> avoid such duplication - if the code can be generic for all new ports it
>> should be in a generic location, while if it's generic for ports with a
>> particular property things should be factored so a port only needs to
>> declare that it has that property. (Of course such refactoring is risky
>> so not typically appropriate during a release freeze.)
>>
>> Often, the files for i386 are actually generic for *old* ports and so if
>> you're copying or including such a file (or one from another old
>> architecture) you need to be particularly careful that it actually
>> represents the desired way to do things now, rather than compatibility
>> with old ABIs or old versions of the syscall interface.
>
> clone is a hodegepodge, but the clone(2) manpage documents it well.
> There are two major camps, and risv implements on of those. And then
> there are various oddballs.
>
> So for now it might make sense to just duplicate the i386 file for
> riscv, or follow the example of various forks to include it. In the
> long run having a generic implementation for the two common versions
> might be useful.
>
Sometime ago I tried to check if it was worth to simplify the arch-fork.h
by defining the supported kernel variations and adding a arch-specific
define (maybe on kernel-features.h). I did not follow up, but I think it
might be feasible: afaik Linux defines 4 variants:
- CONFIG_CLONE_BACKWARDS
- CONFIG_CLONE_BACKWARDS2
- CONFIG_CLONE_BACKWARDS3
- And the generic one which I assume it is meant for newer ports.
So I think we expand the arch-fork.h generic to issue the clone based on
arch-specific flags with a generic one as default. It will make unnecessary
for newer ports to add a arch-fork.h implementation.