On Thu 2017-01-12 17:13:25, Florian Weimer wrote:
> On 01/03/2017 09:54 PM, Pavel Machek wrote:
> >...actually, with strace and batched interface, it will be impossible
> >to see what is going on because of races. So I'm not sure if I like
> >the batched interface at all...
>
> I'm not sure if I u
On 01/03/2017 09:54 PM, Pavel Machek wrote:
...actually, with strace and batched interface, it will be impossible
to see what is going on because of races. So I'm not sure if I like
the batched interface at all...
I'm not sure if I understand this problem.
ioctl, fcntl, most socket system call
> >Hi Florian,
> >
> >I frankly don't understand what you mean, All syscalls you mentioned
> >doesn't take off_t or other 64-bit arguments. 'VM changes' - virtual
> >memory? If so, I don't see any changes in VM with this approach, just
> >correct handling of big offsets.
>
> What I was trying to
This is the draft of sys_mmap64() support in the kernel. For 64-bit
kernels everything is simple. For 32-bit kernels we have a problem.
pgoff_t is declared as unsigned long, and should be turned to
unsigned long long. It affects the number of structures and interfaces.
Last patch does the change.
On Sat 2016-12-10 10:10:01, Pavel Machek wrote:
> Hi!
>
> > > Most of these advantages should eventually go away, when struct-reorg
> > > makes
> > > it way into the compiler. That said, it’s a marginal (but real)
> > > improvement for a
> > > subset of SPEC.
> > >
> > > In the real world, the
Hi!
> > Most of these advantages should eventually go away, when struct-reorg makes
> > it way into the compiler. That said, it’s a marginal (but real) improvement
> > for a
> > subset of SPEC.
> >
> > In the real world, the importance of ILP32 as an aid to transition legacy
> > code
> > that i
On 12/07/2016 04:48 PM, Yury Norov wrote:
On Wed, Dec 07, 2016 at 02:23:55PM +0100, Florian Weimer wrote:
On 12/06/2016 07:54 PM, Yury Norov wrote:
3. Introduce new mmap64() syscall like this:
sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct off_pair
*off);
(The pointer h
On Wednesday, December 7, 2016 5:43:27 PM CET Dr. Philipp Tomsich wrote:
> Catalin,
>
> > On 07 Dec 2016, at 17:32, Catalin Marinas wrote:
> >
> >>> In other words: Why not keep ILP32 simple an ask users that need a 16TB+
> >>> offset
> >>> to use LP64? It seems much more consistent with the ot
Catalin,
> On 07 Dec 2016, at 17:32, Catalin Marinas wrote:
>
>>> In other words: Why not keep ILP32 simple an ask users that need a 16TB+
>>> offset
>>> to use LP64? It seems much more consistent with the other choices takes so
>>> far.
>>
>> If user can switch to lp64, he doesn't need ilp32
On Wed, Dec 07, 2016 at 06:09:44PM +0530, Yury Norov wrote:
> On Wed, Dec 07, 2016 at 12:07:24PM +0100, Dr.Philipp Tomsich wrote:
> > [Resend, as my mail-client had insisted on using the wrong MIME type…]
> >
> > > On 07 Dec 2016, at 11:34, Yury Norov wrote:
> > >
> > >> If there is a use case f
On Wed, Dec 07, 2016 at 02:23:55PM +0100, Florian Weimer wrote:
> On 12/06/2016 07:54 PM, Yury Norov wrote:
> >3. Introduce new mmap64() syscall like this:
> >sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct
> >off_pair *off);
> >(The pointer here because otherwise we have 7
On 12/06/2016 07:54 PM, Yury Norov wrote:
3. Introduce new mmap64() syscall like this:
sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct off_pair
*off);
(The pointer here because otherwise we have 7 args, if simply pass off_hi and
off_lo in registers.)
I would prefer a bat
On Tue, Dec 06, 2016 at 10:20:20PM +0100, Arnd Bergmann wrote:
> On Wednesday, December 7, 2016 12:24:40 AM CET Yury Norov wrote:
> > 3. Introduce new mmap64() syscall like this:
> > sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct
> > off_pair *off);
> > (The pointer here be
On Wednesday, December 7, 2016 12:24:40 AM CET Yury Norov wrote:
> I see 3 solutions for my problem:
> 1. Reuse aarch64/lp64 mmap code for ilp32 in glibc, but wrap offset with
> SYSCALL_LL64() macro - which converts offset to the pair for 32-bit
> ports. This is simple but local solution. And most
Hi all,
(Sorry if there is similar discussion, and I missed it. I didn't
find something in LKML in last half a year.)
In aarch64/ilp32 discussion Catalin wondered why we don't pass offset
in mmap() as 64-bit value (in 2 registers if needed). Looking at kernel
code I found that there's no generic
15 matches
Mail list logo
