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] Y2038: provide kernel support indication


Hi Arnd,

On Wed, 26 Sep 2018 11:02:55 +0200, Arnd Bergmann <arnd@arndb.de>
wrote :

> On Wed, Sep 26, 2018 at 10:54 AM Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
> >
> > Hi Arnd,
> >
> > Le Wed, 26 Sep 2018 10:40:48 +0200, Arnd Bergmann <arnd@arndb.de> a
> > écrit :
> >  
> > > Also, we have to make a hard requirement of using kernel
> > > headers from a fixed version for building the application, so things
> > > like ioctl command numbers, magic mmap() offsets and setsockopt
> > > options can take the right values depending on sizeof(time_t)
> > > to let the kernel know which ABI the user expects.  
> >
> > Since Y2038-proof glibc will require a minimum kernel version to
> > build that is Y2038-proof too (as glibc will need to use the new __NR_*
> > syscall names defined by the kernel). Isn't that requirement enough?  
> 
> Yes, we just have to ensure that the headers contain both the
> syscall number definitions and the updated driver headers. It
> may be that we get the syscall definitions first (some driver interface
> changes are still under discussion, or stalled), and one has to
> ensure that they don't install older kernel headers together with
> a glibc that has been built against the newer version.

"One" here can only be the end user. The best glibc could do would
be to include usr/include/linux/version.h and check LINUX_VERSION_CODE
against a decided-upon minimum version, but maybe the kernel headers
are not there when the public glibc headers are included by an
application source file, so we can't even do that.

Cordialement,
Albert ARIBAUD
3ADEV


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