Re: [PATCH v2 10/15] RISC-V: Linux Syscall Interface

[Palmer Dabbelt <palmer at dabbelt dot com>]

On Wed, 03 Jan 2018 07:56:32 PST (-0800), adhemerval.zanella@linaro.org wrote:
> 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.

I asked on the Linux mailing list what the sane thing to do is here.  Thanks 
for bringing this up, but it might be too late to change anything on our end -- 
there's probably only 1 more Linux RC left, so unless there's a strong reason 
to prefer one argument ordering I think I'm just going to leave it alone.

Sorry we didn't get around to this sooner!