This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



On 08/01/2018 23:30, Palmer Dabbelt wrote:
> 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!

Indeed I also think it is late for this change and my questioning is more for
curiosity. From glibc end, my recent refactor patches are mainly to make glibc
follow what Linux generic api for newer ports intended to do, so new architecture
inclusion would require as less code as possible.

For this refactor in specific riscv will need to define an extra define.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]