On Fri, Jan 18, 2019 at 05:18:35PM +0100, Arnd Bergmann wrote:
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
On Mon, Jan 21, 2019 at 6:08 PM Arnd Bergmann wrote:
> On Mon, Jan 21, 2019 at 9:19 AM Geert Uytterhoeven
> wrote:
> > Regardless, I'm wondering what to do with the holes marked "room for
> > arch specific calls".
> > When is a syscall really arch-specific, and can it be added there, and
> > whe
On Mon, Jan 21, 2019 at 9:19 AM Geert Uytterhoeven wrote:
> On Sat, Jan 19, 2019 at 3:29 PM Russell King - ARM Linux admin
> wrote:
> > On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote:
> > > On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
> > > > On Fri, Jan 18, 2019 at 7:5
On Fri, Jan 18, 2019 at 5:25 PM Arnd Bergmann wrote:
>
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
> This g
On Fri, Jan 18, 2019 at 05:18:35PM +0100, Arnd Bergmann wrote:
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
On Fri, Jan 18, 2019 at 5:25 PM Arnd Bergmann wrote:
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
> This get
Hi Russell,
On Sat, Jan 19, 2019 at 3:29 PM Russell King - ARM Linux admin
wrote:
> On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote:
> > On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
> > > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> > > > On Fri, Jan 18, 201
On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote:
> On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
> >
> > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> > > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
> > > > - Once we get to 512, we clash with the x32 n
On Fri, Jan 18, 2019 at 8:53 PM Andy Lutomirski wrote:
> I think we have two issues if we reuse those numbers for new syscalls.
> First, I'd really like to see new syscalls be numbered consistently
> everywhere, or at least on all x86 variants, and we can't on x32
> because they mean something els
On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
>
> On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
> > > - Once we get to 512, we clash with the x32 numbers (unless
> > > we remove x32 support first), and probably have to s
On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
> > - Once we get to 512, we clash with the x32 numbers (unless
> > we remove x32 support first), and probably have to skip
> > a few more. I also considered using the 512..547 space
On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
>
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
> This g
This adds 21 new system calls on each ABI that has 32-bit time_t
today. All of these have the exact same semantics as their existing
counterparts, and the new ones all have macro names that end in 'time64'
for clarification.
This gets us to the point of being able to safely use a C library
that ha
13 matches
Mail list logo
