On Mon, May 19, 2014 at 9:38 AM, Christoph Hellwig wrote:
> On Mon, May 19, 2014 at 05:35:40PM +0300, Kirill A. Shutemov wrote:
>> >From functional POV, emulation *should* be identical to original
>> remap_file_pages(), but slower. It would be nice, if you test it early.
>>
>> It's not clear yet h
>> Mirrored mapping is absolutely required by several
>> independent proprietary platforms I'm aware of, and remap_file_pages()
>> has historically been the only sane way to accomplish this. (i.e.,
>> shm_open(), mmap(NULL, 2^(n+1) pages), remap_file_pages() on 2nd
>> half).
>
> Em.. What's wrong w
lo Bonzini wrote:
> Il 26/05/2014 15:24, Jeff Smith ha scritto:
>
>> Your addr2 mmap() call is a bit incorrect semantically and
>> syntactically (you skipped the length arg). The addr2 request will
>> fail because mmap() does not implicitly munmap() occupied virtual
>> add
religious
about checking dmesg.
--Jeff
On Mon, May 26, 2014 at 8:47 AM, Kirill A. Shutemov
wrote:
> Jeff Smith wrote:
>> OK, I misinterpreted "the overlapped part of the mapping(s) will be
>> discarded" as discarding the -new- mappings. My objections about
>>
inotify's behavior concerning events from removed watches (they do
happen) and watch descriptor reuse (beyond my knowledge) is currently
undocumented.
Although it mimics a standard multiplexing interface in most regards,
writing a robust user-space handler is comparatively more complex due
to the
h/read look and feel more like
open/epoll_ctl(EPOLL_CTL_ADD))/epoll_wait would be my ultimate wish.
The asynchronous-feeling handle removal is not a great interface in
general to deal with.
Best regards,
Jeff
On Tue, May 27, 2014 at 2:32 PM, Heinrich Schuchardt wrote:
> On 27.05.2014 19:25
6 matches
Mail list logo
