On Tue, Jul 17, 2018 at 2:58 PM, Christoph Hellwig wrote:
> On Mon, Jul 16, 2018 at 12:11:53PM +0200, Arnd Bergmann wrote:
>> I don't think it makes a big difference whether we change it now or later,
>> but if Christoph feels that it addresses his concern about the compat_
>> namespace being reus
On Mon, Jul 16, 2018 at 12:11:53PM +0200, Arnd Bergmann wrote:
> I don't think it makes a big difference whether we change it now or later,
> but if Christoph feels that it addresses his concern about the compat_
> namespace being reused during the transition, doing it earlier would
> enable us to
On Sat, Jul 14, 2018 at 5:54 PM, Deepa Dinamani wrote:
> Right now we only have compat syscalls and native syscalls.
> Until we transition all the architectures to use the new syscalls,
> wouldn't it be the same sort of confusion as exists today?
> These structures today are still used by compat e
Right now we only have compat syscalls and native syscalls.
Until we transition all the architectures to use the new syscalls,
wouldn't it be the same sort of confusion as exists today?
These structures today are still used by compat entry points.
I'm trying to understand why such a cleanup would m
Christoph Hellwig suggested a slightly different path for handling
backwards compatibility with the 32-bit time_t based system calls:
Rather than simply reusing the compat_sys_* entry points on 32-bit
architectures unchanged, we get rid of those entry points and the
compat_time types by renaming t
