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, Jeff Smith wr
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
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
, Jeff Smith wrote:
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
king 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
>> needing a replacemen
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
>> 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
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 with
...@redhat.com 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
address space.
With MAP_FIXED
.
--Jeff
On Mon, May 26, 2014 at 8:47 AM, Kirill A. Shutemov
kirill.shute...@linux.intel.com 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
needing a replacement for remap_file_pages
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
On Mon, May 19, 2014 at 9:38 AM, Christoph Hellwig h...@infradead.org 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
12 matches
Mail list logo
