Re: [PATCH V10 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

[Thomas Gleixner]

On Tue, 20 Jun 2017, Daniel Lezcano wrote:
> On Tue, Jun 20, 2017 at 04:05:07PM +0200, Thomas Gleixner wrote:
> > On Mon, 12 Jun 2017, Daniel Lezcano wrote:
> > > But, the API request_percpu_irq does not allow to pass a flag, hence 
> > > specifying
> > > if the interrupt type is a timer.
> > > 
> > > Add a function request_percpu_irq_flags() where we can specify the flags. 
> > > The
> > > request_percpu_irq() function is changed to be a wrapper to
> > > request_percpu_irq_flags() passing a zero flag parameter.
> > 
> > And exactly this change wants to be a separate patch. We do not make whole
> > sale changes this way. You should know that already and someone pointed
> > that out to you in some of the earlier versions.
> > 
> > > -int request_percpu_irq(unsigned int irq, irq_handler_t handler,
> > > -const char *devname, void __percpu *dev_id)
> > > +int request_percpu_irq_flags(unsigned int irq, irq_handler_t handler,
> > 
> > The function name sucks. The first time I read it, it meant request the per
> > cpu irq flags, which is not what you aim at, right?
> > 
> > Please make that __request_percpu_irq() for now and on -rc1 time provide a
> > patch set to convert all current request_percpu_irq() users to have the
> > extra argument and then remove the __request_percpu_irq() intermediate.
> 
> Ok, I will the change this way.
> 
> What about 2/3 and 3/3? Is it possible to take them with the
> __request_percpu_irq change?

The rest looks ok. Please repost.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V10 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

[Daniel Lezcano]

On 20/06/2017 22:29, Thomas Gleixner wrote:
> On Tue, 20 Jun 2017, Daniel Lezcano wrote:
>> On Tue, Jun 20, 2017 at 04:05:07PM +0200, Thomas Gleixner wrote:
>>> On Mon, 12 Jun 2017, Daniel Lezcano wrote:
 But, the API request_percpu_irq does not allow to pass a flag, hence 
 specifying
 if the interrupt type is a timer.

 Add a function request_percpu_irq_flags() where we can specify the flags. 
 The
 request_percpu_irq() function is changed to be a wrapper to
 request_percpu_irq_flags() passing a zero flag parameter.
>>>
>>> And exactly this change wants to be a separate patch. We do not make whole
>>> sale changes this way. You should know that already and someone pointed
>>> that out to you in some of the earlier versions.
>>>
 -int request_percpu_irq(unsigned int irq, irq_handler_t handler,
 - const char *devname, void __percpu *dev_id)
 +int request_percpu_irq_flags(unsigned int irq, irq_handler_t handler,
>>>
>>> The function name sucks. The first time I read it, it meant request the per
>>> cpu irq flags, which is not what you aim at, right?
>>>
>>> Please make that __request_percpu_irq() for now and on -rc1 time provide a
>>> patch set to convert all current request_percpu_irq() users to have the
>>> extra argument and then remove the __request_percpu_irq() intermediate.
>>
>> Ok, I will the change this way.
>>
>> What about 2/3 and 3/3? Is it possible to take them with the
>> __request_percpu_irq change?
> 
> The rest looks ok. Please repost.

Ok, thanks.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V10 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

[Daniel Lezcano]

On Tue, Jun 20, 2017 at 04:05:07PM +0200, Thomas Gleixner wrote:
> On Mon, 12 Jun 2017, Daniel Lezcano wrote:
> > But, the API request_percpu_irq does not allow to pass a flag, hence 
> > specifying
> > if the interrupt type is a timer.
> > 
> > Add a function request_percpu_irq_flags() where we can specify the flags. 
> > The
> > request_percpu_irq() function is changed to be a wrapper to
> > request_percpu_irq_flags() passing a zero flag parameter.
> 
> And exactly this change wants to be a separate patch. We do not make whole
> sale changes this way. You should know that already and someone pointed
> that out to you in some of the earlier versions.
> 
> > -int request_percpu_irq(unsigned int irq, irq_handler_t handler,
> > -  const char *devname, void __percpu *dev_id)
> > +int request_percpu_irq_flags(unsigned int irq, irq_handler_t handler,
> 
> The function name sucks. The first time I read it, it meant request the per
> cpu irq flags, which is not what you aim at, right?
> 
> Please make that __request_percpu_irq() for now and on -rc1 time provide a
> patch set to convert all current request_percpu_irq() users to have the
> extra argument and then remove the __request_percpu_irq() intermediate.

Ok, I will the change this way.

What about 2/3 and 3/3? Is it possible to take them with the
__request_percpu_irq change?



-- 

  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list

[Arnd Bergmann]

On Tue, Jun 20, 2017 at 4:54 PM, Yury Norov  wrote:
> On Tue, Jun 20, 2017 at 04:20:43PM +0200, Arnd Bergmann wrote:
>> On Tue, Jun 20, 2017 at 3:37 PM, Yury Norov  
>> wrote:
>> > On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote:
>> >> On Mon, Jun 19, 2017 at 11:58:41PM +0200, Arnd Bergmann wrote:

>> > I would also notice riscv people and welcome to the discussion.
>> >
>> > As there is more than 1 arch that goes to be added to linux soon,
>> > maybe it's better to upstream my ans James' patches separately
>> > from other ilp32 patches? Arnd?
>>
>> Do you mean upstream those two patches slightly later? That's
>> fine with me, I don't care much whether the old new stat is part
>> of the syscall table for arm64-ilp32 or not, I'd leave that up to
>> you, depending on whether you want to do the rework or not.
>
> I mean that if we want to deprecate rlimit and stat syscalls for
> architectures that are under development now, it's better to upstream
> patches that actually deprecate it as early as possible.

Makes sense.

>> I suppose the arm64-ilp32 could benefit from not having to support
>> the old arm32 stat structure, but doing the new syscalls based on
>> statx could delay the glibc port some more, as there are some open
>> questions about how that would best be integrated.
>
> OK. Let's leave things as is. But then I don't see any reason to
> add unxstat patch to ilp32 series if ilp32 will not disable it.

Right, that's what I meant: let's leave the rlimit patch in your series
as it matches the work you have already done, and is the right
thing to do, and let's do the unxstat patch separately so it doesn't
cause you extra work.

Arnd

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list

[Yury Norov]

On Tue, Jun 20, 2017 at 04:20:43PM +0200, Arnd Bergmann wrote:
> On Tue, Jun 20, 2017 at 3:37 PM, Yury Norov  wrote:
> > On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote:
> >> On Mon, Jun 19, 2017 at 11:58:41PM +0200, Arnd Bergmann wrote:
> >> > On Mon, Jun 19, 2017 at 11:42 PM, James Hogan  
> >> > wrote:
> >> > > On Mon, Jun 19, 2017 at 06:49:46PM +0300, Yury Norov wrote:
> >> > > Subject: [PATCH] Deprecate stat syscalls superseded by statx
> >> > >
> >> > > Various stat system calls can now be implemented as userland wrappers
> >> > > around the new statx system call, so allow them to be removed from the
> >> > > kernel by default for new architectures / ABIs.
> >> > >
> >> > > This involves adding __ARCH_WANT_SYSCALL_UNXSTAT to each existing
> >> > > architecture, which enables the relevant stat system calls in the
> >> > > generic system call list (if used). It also conditionally defines the
> >> > > syscalls in fs/stat.c and struct stat / struct stat64 in
> >> > > asm-generic/stat.h.
> >> > >
> >> > > Signed-off-by: James Hogan 
> >> > > Cc: David Howells 
> >> > > Cc: Alexander Viro 
> >> > > Cc: Arnd Bergmann 
> >> > > Cc: linux-fsde...@vger.kernel.org
> >> > > Cc: linux-a...@vger.kernel.org
> >> > > Cc: linux-...@vger.kernel.org
> >> > > Cc: linux-ker...@vger.kernel.org
> >> >
> >> > Good idea:
> >> >
> >> > Acked-by:  Arnd Bergmann 
> >> > > +/* statx deprecates the un-extended stat syscalls which use struct 
> >> > > stat[64] */
> >> > > +#ifdef __ARCH_WANT_SYSCALL_UNXSTAT
> >> >
> >> > I'm glad you explain what 'UNXSTAT' means here, since I would not
> >> > have otherwise guessed it, but I also can't think of anything more
> >> > intuitive.
> >>
> >> Yeh, I renamed that several times while playing around with this :-).
> >>
> >> The stat syscalls remind me a bit of the Vicar of Dibley episode where
> >> the new road named "New Road" necessitates the renaming of the existing
> >> "New Road" to "Quite Old Road" and "Quite Old Road" to "Really Quite Old
> >> Road" and "Old Road" to "Very Old Road"!
> >
> > (Add Palmer Dabbelt )
> >
> > The stat syscalls are full of hacks, and we have to pull that hacks
> > even to new architectures to deal with stat. So I'll be happy to drop
> > it in arm64/ilp32. But it means that I need some time to integrate
> > your patch and fix glibc accordingly. And it also means that we need
> > round 9 for ilp32... :(
> >
> > Arnd, once before you told that generic unistd has some duplications
> > and legacy syscalls, and one day we'll have to deal with it. Do you
> > have the list or something on it?
> 
> No, I'd have to do some research for that.
> 
> > I would also notice riscv people and welcome to the discussion.
> >
> > As there is more than 1 arch that goes to be added to linux soon,
> > maybe it's better to upstream my ans James' patches separately
> > from other ilp32 patches? Arnd?
> 
> Do you mean upstream those two patches slightly later? That's
> fine with me, I don't care much whether the old new stat is part
> of the syscall table for arm64-ilp32 or not, I'd leave that up to
> you, depending on whether you want to do the rework or not.
 
I mean that if we want to deprecate rlimit and stat syscalls for
architectures that are under development now, it's better to upstream
patches that actually deprecate it as early as possible. 

> I suppose the arm64-ilp32 could benefit from not having to support
> the old arm32 stat structure, but doing the new syscalls based on
> statx could delay the glibc port some more, as there are some open
> questions about how that would best be integrated.

OK. Let's leave things as is. But then I don't see any reason to
add unxstat patch to ilp32 series if ilp32 will not disable it.

Yury

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list

[Arnd Bergmann]

On Tue, Jun 20, 2017 at 3:37 PM, Yury Norov  wrote:
> On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote:
>> On Mon, Jun 19, 2017 at 11:58:41PM +0200, Arnd Bergmann wrote:
>> > On Mon, Jun 19, 2017 at 11:42 PM, James Hogan  
>> > wrote:
>> > > On Mon, Jun 19, 2017 at 06:49:46PM +0300, Yury Norov wrote:
>> > > Subject: [PATCH] Deprecate stat syscalls superseded by statx
>> > >
>> > > Various stat system calls can now be implemented as userland wrappers
>> > > around the new statx system call, so allow them to be removed from the
>> > > kernel by default for new architectures / ABIs.
>> > >
>> > > This involves adding __ARCH_WANT_SYSCALL_UNXSTAT to each existing
>> > > architecture, which enables the relevant stat system calls in the
>> > > generic system call list (if used). It also conditionally defines the
>> > > syscalls in fs/stat.c and struct stat / struct stat64 in
>> > > asm-generic/stat.h.
>> > >
>> > > Signed-off-by: James Hogan 
>> > > Cc: David Howells 
>> > > Cc: Alexander Viro 
>> > > Cc: Arnd Bergmann 
>> > > Cc: linux-fsde...@vger.kernel.org
>> > > Cc: linux-a...@vger.kernel.org
>> > > Cc: linux-...@vger.kernel.org
>> > > Cc: linux-ker...@vger.kernel.org
>> >
>> > Good idea:
>> >
>> > Acked-by:  Arnd Bergmann 
>> > > +/* statx deprecates the un-extended stat syscalls which use struct 
>> > > stat[64] */
>> > > +#ifdef __ARCH_WANT_SYSCALL_UNXSTAT
>> >
>> > I'm glad you explain what 'UNXSTAT' means here, since I would not
>> > have otherwise guessed it, but I also can't think of anything more
>> > intuitive.
>>
>> Yeh, I renamed that several times while playing around with this :-).
>>
>> The stat syscalls remind me a bit of the Vicar of Dibley episode where
>> the new road named "New Road" necessitates the renaming of the existing
>> "New Road" to "Quite Old Road" and "Quite Old Road" to "Really Quite Old
>> Road" and "Old Road" to "Very Old Road"!
>
> (Add Palmer Dabbelt )
>
> The stat syscalls are full of hacks, and we have to pull that hacks
> even to new architectures to deal with stat. So I'll be happy to drop
> it in arm64/ilp32. But it means that I need some time to integrate
> your patch and fix glibc accordingly. And it also means that we need
> round 9 for ilp32... :(
>
> Arnd, once before you told that generic unistd has some duplications
> and legacy syscalls, and one day we'll have to deal with it. Do you
> have the list or something on it?

No, I'd have to do some research for that.

> I would also notice riscv people and welcome to the discussion.
>
> As there is more than 1 arch that goes to be added to linux soon,
> maybe it's better to upstream my ans James' patches separately
> from other ilp32 patches? Arnd?

Do you mean upstream those two patches slightly later? That's
fine with me, I don't care much whether the old new stat is part
of the syscall table for arm64-ilp32 or not, I'd leave that up to
you, depending on whether you want to do the rework or not.

I suppose the arm64-ilp32 could benefit from not having to support
the old arm32 stat structure, but doing the new syscalls based on
statx could delay the glibc port some more, as there are some open
questions about how that would best be integrated.

   Arnd

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list

[Yury Norov]

On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote:
> On Mon, Jun 19, 2017 at 11:58:41PM +0200, Arnd Bergmann wrote:
> > On Mon, Jun 19, 2017 at 11:42 PM, James Hogan  
> > wrote:
> > > On Mon, Jun 19, 2017 at 06:49:46PM +0300, Yury Norov wrote:
> > > Subject: [PATCH] Deprecate stat syscalls superseded by statx
> > >
> > > Various stat system calls can now be implemented as userland wrappers
> > > around the new statx system call, so allow them to be removed from the
> > > kernel by default for new architectures / ABIs.
> > >
> > > This involves adding __ARCH_WANT_SYSCALL_UNXSTAT to each existing
> > > architecture, which enables the relevant stat system calls in the
> > > generic system call list (if used). It also conditionally defines the
> > > syscalls in fs/stat.c and struct stat / struct stat64 in
> > > asm-generic/stat.h.
> > >
> > > Signed-off-by: James Hogan 
> > > Cc: David Howells 
> > > Cc: Alexander Viro 
> > > Cc: Arnd Bergmann 
> > > Cc: linux-fsde...@vger.kernel.org
> > > Cc: linux-a...@vger.kernel.org
> > > Cc: linux-...@vger.kernel.org
> > > Cc: linux-ker...@vger.kernel.org
> > 
> > Good idea:
> > 
> > Acked-by:  Arnd Bergmann 
> 
> Thanks,
> 
> > 
> > > +/* statx deprecates the un-extended stat syscalls which use struct 
> > > stat[64] */
> > > +#ifdef __ARCH_WANT_SYSCALL_UNXSTAT
> > 
> > I'm glad you explain what 'UNXSTAT' means here, since I would not
> > have otherwise guessed it, but I also can't think of anything more
> > intuitive.
> 
> Yeh, I renamed that several times while playing around with this :-).
> 
> The stat syscalls remind me a bit of the Vicar of Dibley episode where
> the new road named "New Road" necessitates the renaming of the existing
> "New Road" to "Quite Old Road" and "Quite Old Road" to "Really Quite Old
> Road" and "Old Road" to "Very Old Road"!
> 
> Cheers
> James

(Add Palmer Dabbelt )

The stat syscalls are full of hacks, and we have to pull that hacks
even to new architectures to deal with stat. So I'll be happy to drop
it in arm64/ilp32. But it means that I need some time to integrate
your patch and fix glibc accordingly. And it also means that we need
round 9 for ilp32... :(

Arnd, once before you told that generic unistd has some duplications
and legacy syscalls, and one day we'll have to deal with it. Do you
have the list or something on it?

I would also notice riscv people and welcome to the discussion.  

As there is more than 1 arch that goes to be added to linux soon,
maybe it's better to upstream my ans James' patches separately
from other ilp32 patches? Arnd?

Yury

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list

[Yury Norov]

On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote:
> On Mon, Jun 19, 2017 at 11:58:41PM +0200, Arnd Bergmann wrote:
> > On Mon, Jun 19, 2017 at 11:42 PM, James Hogan  
> > wrote:
> > > On Mon, Jun 19, 2017 at 06:49:46PM +0300, Yury Norov wrote:
> > > Subject: [PATCH] Deprecate stat syscalls superseded by statx
> > >
> > > Various stat system calls can now be implemented as userland wrappers
> > > around the new statx system call, so allow them to be removed from the
> > > kernel by default for new architectures / ABIs.
> > >
> > > This involves adding __ARCH_WANT_SYSCALL_UNXSTAT to each existing
> > > architecture, which enables the relevant stat system calls in the
> > > generic system call list (if used). It also conditionally defines the
> > > syscalls in fs/stat.c and struct stat / struct stat64 in
> > > asm-generic/stat.h.
> > >
> > > Signed-off-by: James Hogan 
> > > Cc: David Howells 
> > > Cc: Alexander Viro 
> > > Cc: Arnd Bergmann 
> > > Cc: linux-fsde...@vger.kernel.org
> > > Cc: linux-a...@vger.kernel.org
> > > Cc: linux-...@vger.kernel.org
> > > Cc: linux-ker...@vger.kernel.org
> > 
> > Good idea:
> > 
> > Acked-by:  Arnd Bergmann 
> 
> Thanks,
> 
> > 
> > > +/* statx deprecates the un-extended stat syscalls which use struct 
> > > stat[64] */
> > > +#ifdef __ARCH_WANT_SYSCALL_UNXSTAT
> > 
> > I'm glad you explain what 'UNXSTAT' means here, since I would not
> > have otherwise guessed it, but I also can't think of anything more
> > intuitive.
> 
> Yeh, I renamed that several times while playing around with this :-).
> 
> The stat syscalls remind me a bit of the Vicar of Dibley episode where
> the new road named "New Road" necessitates the renaming of the existing
> "New Road" to "Quite Old Road" and "Quite Old Road" to "Really Quite Old
> Road" and "Old Road" to "Very Old Road"!
> 
> Cheers
> James

(Add Palmer Dabbelt )

The stat syscalls are full of hacks, and we have to pull that hacks
even to new architectures to deal with stat. So I'll be happy to drop
it in arm64/ilp32. But it means that I need some time to integrate
your patch and fix glibc accordingly. And it also means that we need
round 9 for ilp32... :(

Arnd, once before you told that generic unistd has some duplications
and legacy syscalls, and one day we'll have to deal with it. Do you
have the list or something on it?

I would also like to notice riscv people and welcome to the discussion.  

As there is more than 1 arch that goes to be added to linux soon,
maybe it's better to upstream my ans James' patches separately
from other ilp32 patches? Arnd?

Yury

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH V10 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request

[Thomas Gleixner]

On Mon, 12 Jun 2017, Daniel Lezcano wrote:
> But, the API request_percpu_irq does not allow to pass a flag, hence 
> specifying
> if the interrupt type is a timer.
> 
> Add a function request_percpu_irq_flags() where we can specify the flags. The
> request_percpu_irq() function is changed to be a wrapper to
> request_percpu_irq_flags() passing a zero flag parameter.

And exactly this change wants to be a separate patch. We do not make whole
sale changes this way. You should know that already and someone pointed
that out to you in some of the earlier versions.

> -int request_percpu_irq(unsigned int irq, irq_handler_t handler,
> -const char *devname, void __percpu *dev_id)
> +int request_percpu_irq_flags(unsigned int irq, irq_handler_t handler,

The function name sucks. The first time I read it, it meant request the per
cpu irq flags, which is not what you aim at, right?

Please make that __request_percpu_irq() for now and on -rc1 time provide a
patch set to convert all current request_percpu_irq() users to have the
extra argument and then remove the __request_percpu_irq() intermediate.

Thanks,

tglx

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list

[Yury Norov]

On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote:
> On Mon, Jun 19, 2017 at 11:58:41PM +0200, Arnd Bergmann wrote:
> > On Mon, Jun 19, 2017 at 11:42 PM, James Hogan  
> > wrote:
> > > On Mon, Jun 19, 2017 at 06:49:46PM +0300, Yury Norov wrote:
> > > Subject: [PATCH] Deprecate stat syscalls superseded by statx
> > >
> > > Various stat system calls can now be implemented as userland wrappers
> > > around the new statx system call, so allow them to be removed from the
> > > kernel by default for new architectures / ABIs.
> > >
> > > This involves adding __ARCH_WANT_SYSCALL_UNXSTAT to each existing
> > > architecture, which enables the relevant stat system calls in the
> > > generic system call list (if used). It also conditionally defines the
> > > syscalls in fs/stat.c and struct stat / struct stat64 in
> > > asm-generic/stat.h.
> > >
> > > Signed-off-by: James Hogan 
> > > Cc: David Howells 
> > > Cc: Alexander Viro 
> > > Cc: Arnd Bergmann 
> > > Cc: linux-fsde...@vger.kernel.org
> > > Cc: linux-a...@vger.kernel.org
> > > Cc: linux-...@vger.kernel.org
> > > Cc: linux-ker...@vger.kernel.org
> > 
> > Good idea:
> > 
> > Acked-by:  Arnd Bergmann 
> 
> Thanks,
> 
> > 
> > > +/* statx deprecates the un-extended stat syscalls which use struct 
> > > stat[64] */
> > > +#ifdef __ARCH_WANT_SYSCALL_UNXSTAT
> > 
> > I'm glad you explain what 'UNXSTAT' means here, since I would not
> > have otherwise guessed it, but I also can't think of anything more
> > intuitive.
> 
> Yeh, I renamed that several times while playing around with this :-).
> 
> The stat syscalls remind me a bit of the Vicar of Dibley episode where
> the new road named "New Road" necessitates the renaming of the existing
> "New Road" to "Quite Old Road" and "Quite Old Road" to "Really Quite Old
> Road" and "Old Road" to "Very Old Road"!
> 
> Cheers
> James

(Add Palmer Dabbelt )

The stat syscalls are full of hacks, and we have to pull that hacks
even to new architectures to deal with stat. So I'll be happy to drop
it in arm64/ilp32. But it means that I need some time to integrate
your patch and fix glibc accordingly. And it also means that we need
round 9 for ilp32... :(

Arnd, once before you told that generic unistd has some duplications
and legacy syscalls, and one day we'll have to deal with it. Do you
have the list or something on it?

I would also notice riscv people and welcome to the discussion.  

As there is more than 1 arch that goes to be added to linux soon,
maybe it's better to upstream my ans James' patches separately
from other ilp32 patches? Arnd?

Yury

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc