jlaitine commented on PR #6025: URL: https://github.com/apache/incubator-nuttx/pull/6025#issuecomment-1108710905
> > There is nothing else than the inode pointer which is usable in UNMAP ioctl. > > It depends on the driver implementation. For example, both tmpfs/romfs access file->priv in FIOC_MAP ioctl. Yes, tmpfs/romfs doesn't implement FIOC_UNMAP ioctl yet, but if they want to implement FIOC_UNMAP in the future, it will access file->priv field definitely. No, it couldn't if the originally mmapped file is already closed. File->priv would be a private pointer from another open call for another file struct. > > > Any other info would be bogus. What is the "contract" you mention? > > file_operation_s is designed as follow: > > 1. file_operation_s::open is the first call, the per file initialization could be done here > 2. Other callback(read/write/ioctl/seek) in file_operation_s can reference the per file private data > 3. file_operation_s::close is the last call, and driver can release the resource allocated in step 1 This is true, but only applies to operations on an open file. Munmap can be done even in case the file is unliked, not only closed. > > For open/close in some implementation may be no-op, but isn't always true. @pkarashchenko clean up the first case recently: > https://github.com/apache/incubator-nuttx/pull/6053 > mmap need make both implementation happy. Yes, but this is not about open/close being no-op for the driver. The point is that you just can't use file struct in munmap, since the original file struct may not exist any more. This is different in linux where they actually preserve the original file struct via a reference counter. > > > > > I can add the gran allocator handle still into vm_map, and remove the separate shm's one. Unfortunately I have time for this PR on next Tuesday at earliest > > no problem. So is the more generic way how I added the allocators into vm_map usable, or do you want to revert back to simpler structure and just have the gran handle for shm in group struct? > -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
