On Wed, 28 Sep 2016, Albert ARIBAUD wrote:
> - make Y2038-safe kernel provide a new syscall which tells at run time
> what features the kernel supports, e.g. does it support 64-bit time,
> 32-bit time, both? [the need could be more generic than just time
> support, so I tought such a syscall
Hi Arnd,
On Wed, 29 Jun 2016 16:02:13 +0200, Arnd Bergmann
wrote :
> On Wednesday, June 29, 2016 1:16:11 PM CEST Albert ARIBAUD wrote:
> >
> > On Wed, 22 Jun 2016 13:55:16 +0200, Arnd Bergmann
> > wrote :
> >
> > > On your note "The implementation needs further thinking about, as
> > > appl
Hi Arnd,
On Thu, 14 Jul 2016 13:39:13 +0200, Arnd Bergmann
wrote :
> On Wednesday, July 13, 2016 7:38:25 PM CEST Deepa Dinamani wrote:
> > On Wed, Jul 13, 2016 at 1:40 PM, Deepa Dinamani
> > wrote:
>
> [...]
> [...]
> > >
> > > Another way of handling this would be to use the flags in
On Wednesday, July 13, 2016 7:38:25 PM CEST Deepa Dinamani wrote:
> On Wed, Jul 13, 2016 at 1:40 PM, Deepa Dinamani
> wrote:
> >>> == Socket options ==
> >>>
> >>> Like ioctl(), setsockopt()/getsockopt() has a few interfaces that are
> >>> passing time data:
> >>>
> >>> SO_TIMESTAMP/SO_TIMESTAMP
On Wed, Jul 13, 2016 at 1:40 PM, Deepa Dinamani wrote:
>>> I think we should expand the ioctl section a bit: I can do most of it
>>> in the kernel, but need help from glibc for a few things in which we
>>> need to agree on calling conventions. Here is what I'd suggest having in
>>> the document, f
>> I think we should expand the ioctl section a bit: I can do most of it
>> in the kernel, but need help from glibc for a few things in which we
>> need to agree on calling conventions. Here is what I'd suggest having in
>> the document, feel free to take that into your document or edit as you
>> w
On Wednesday, June 29, 2016 1:16:11 PM CEST Albert ARIBAUD wrote:
>
> On Wed, 22 Jun 2016 13:55:16 +0200, Arnd Bergmann
> wrote :
>
> > On your note "The implementation needs further thinking about, as
> > application code defining _TIME_BITS=64 and gets built against
> > new kernel headers and
On Wednesday, June 29, 2016 11:58:38 AM CEST Albert ARIBAUD wrote:
> > == IOCTLs and Y2038 ==
> >
> > Some Linux IOCTLs may be Y2038-unsafe, or use types defined by glibc
> > that do not match the kernel internal types. Known important cases are:
> >
> > - An ioctl command number is defined u
Hi Arnd,
On Wed, 22 Jun 2016 13:55:16 +0200, Arnd Bergmann
wrote :
> On your note "The implementation needs further thinking about, as
> application code defining _TIME_BITS=64 and gets built against
> new kernel headers and old GLIBC headers, then GLIBC will use 32-bit
> time_t and kernel will
Hi Arnd,
On Wed, 22 Jun 2016 13:55:16 +0200, Arnd Bergmann
wrote :
> I noticed 'struct sysinfo' as another interface that holds a time,
> even though this is documented as 'long' and I concluded that we
> won't need to change it, that should probably be documented.
Added, thanks.
> 'struct rus
On Thursday, June 23, 2016 4:56:00 PM CEST Joseph Myers wrote:
> On Thu, 23 Jun 2016, Arnd Bergmann wrote:
>
> > Is there a policy about what justifies such an ABI break? I.e. is it
>
> The clear implication from the discussions around C++11 support in
> libstdc++, which resulted in the complica
On Thu, 23 Jun 2016, Arnd Bergmann wrote:
> Is there a policy about what justifies such an ABI break? I.e. is it
The clear implication from the discussions around C++11 support in
libstdc++, which resulted in the complicated ABI tag infrastructure, is
that changing the libstdc++ SONAME would no
On Thursday, June 23, 2016 2:32:50 PM CEST Joseph Myers wrote:
> On Thu, 23 Jun 2016, Arnd Bergmann wrote:
>
> > > I'd be a lot more comfortable with requiring new kernel headers to build
> > > and use glibc than with requiring a new kernel at runtime for
> > > _TIME_BITS=64 to work. New kernel
On Thu, 23 Jun 2016, Arnd Bergmann wrote:
> > I'd be a lot more comfortable with requiring new kernel headers to build
> > and use glibc than with requiring a new kernel at runtime for
> > _TIME_BITS=64 to work. New kernel headers are one of the easiest things
> > to use when building glibc, s
On Wednesday, June 22, 2016 8:19:36 PM CEST Joseph Myers wrote:
> On Wed, 22 Jun 2016, Arnd Bergmann wrote:
>
> > We can avoid most of the problems if building with _TIME_BITS=64
> > has no effect unless both glibc and the kernel headers are new
> > enough to provide the definitions for 64-bit tim
On Wed, 22 Jun 2016, Arnd Bergmann wrote:
> We can avoid most of the problems if building with _TIME_BITS=64
> has no effect unless both glibc and the kernel headers are new
> enough to provide the definitions for 64-bit time_t. That way
> we can at least ensure that calling an ioctl command or se
On Wednesday, June 22, 2016 2:30:10 PM CEST Joseph Myers wrote:
> On Wed, 22 Jun 2016, Arnd Bergmann wrote:
>
> > Regarding the "Support for non-Y2038-safe kernels" section, I'm not
> > sure if that can work at all: A kernel that does not have the appropriate
> > system calls will also not have th
On Wed, 22 Jun 2016, Arnd Bergmann wrote:
> Regarding the "Support for non-Y2038-safe kernels" section, I'm not
> sure if that can work at all: A kernel that does not have the appropriate
> system calls will also not have the handlers for a lot of the ioctl
> commands and possibly other interfaces
On Wednesday, June 22, 2016 12:58:38 AM CEST Albert ARIBAUD wrote:
> Hi all,
>
> I have produced a fourth draft of what will eventually become the Y2038
> design document:
>
> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=83
>
> Relative to the previous draft:
>
> * the scope clar
19 matches
Mail list logo
