Re: [Question] New mmap64 syscall?

From	Pavel Machek <pavel@ucw.cz>
Newsgroups	linux.kernel
Subject	Re: [Question] New mmap64 syscall?
Date	2017-01-03 22:10 +0100
Message-ID	<sVEvh-3xp-71@gated-at.bofh.it> (permalink)
References	<sLvtf-7oy-21@gated-at.bofh.it> <sLKsh-BZ-11@gated-at.bofh.it> <sM9h5-7Vv-17@gated-at.bofh.it> <sM9h5-7Vv-15@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

> >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 suggest is a completely different interface which is
> not subject to register size constraints and which has been requested before
> (a mechanism for batching mm updates).

While I agree that batching might be good idea, I believe mmap64()
makes sense, too. Yes, I guess libc could do the translation, but
indirection will cost some performance, and will be problematic for
stuff such as strace.

...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...

Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: [Question] New mmap64 syscall? Pavel Machek <pavel@ucw.cz> - 2017-01-03 22:10 +0100
  Re: [Question] New mmap64 syscall? Florian Weimer <fweimer@redhat.com> - 2017-01-12 17:20 +0100
    Re: [Question] New mmap64 syscall? Pavel Machek <pavel@ucw.cz> - 2017-01-12 23:00 +0100

csiph-web