On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Fri, 17 Nov 2017, Arnd Bergmann wrote:
>> On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>> > On Wed, 15 Nov 2017, Deepa Dinamani wrote:
>> >> Would this work for everyone?
>> >
>> > Having extra config switches which are selectable by architectures and
>> > removed when everything is converted is definitely the right way to go.
>> >
>> > That allows you to gradually convert stuff w/o inflicting wreckage all over
>> > the place.
>>
>> The CONFIG_64BIT_TIME would do that nicely for the new stuff like
>> the conditional definition of __kernel_timespec, this one would get
>> removed after we convert all architectures.
>>
>> A second issue is how to control the compilation of the compat syscalls.
>> CONFIG_COMPAT_32BIT_TIME handles that and could be defined
>> in Kconfig as 'def_bool (!64BIT && CONFIG_64BIT_TIME) || COMPAT',
>> this is then just a more readable way of expressing exactly when the
>> functions should be built.
>>
>> For completeness, there may be a third category, depending on how
>> we handle things like sys_nanosleep(): Here, we want the native
>> sys_nanosleep on 64-bit architectures, and compat_sys_nanosleep()
>> to handle the 32-bit time_t variant on both 32-bit and 64-bit targets,
>> but our plan is to not have a native 32-bit sys_nanosleep on 32-bit
>> architectures any more, as new glibc should call clock_nanosleep()
>> with a new syscall number instead. Should we then enclose
>
> Isn't that going to break existing userspace?
No, syscall that existing 32-bit user space enters would be handled by
compat_sys_nanosleep() on both 32-bit and 64-bit kernels at that
point. The idea here is to make the code path more uniform between
32-bit and 64-bit kernels.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
