jlaitine commented on code in PR #8000:
URL: https://github.com/apache/nuttx/pull/8000#discussion_r1059922840


##########
include/nuttx/fs/fs.h:
##########
@@ -206,16 +207,21 @@ struct file_operations
    * treated like unions.
    */
 
-  int     (*close)(FAR struct file *filep);
-  ssize_t (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
-  ssize_t (*write)(FAR struct file *filep, FAR const char *buffer,
-                   size_t buflen);
-  off_t   (*seek)(FAR struct file *filep, off_t offset, int whence);
-  int     (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
+  int      (*close)(FAR struct file *filep);
+  ssize_t  (*read)(FAR struct file *filep, FAR char *buffer, size_t buflen);
+  ssize_t  (*write)(FAR struct file *filep, FAR const char *buffer,
+                    size_t buflen);
+  off_t    (*seek)(FAR struct file *filep, off_t offset, int whence);
+  int      (*ioctl)(FAR struct file *filep, int cmd, unsigned long arg);
+  int      (*truncate)(FAR struct file *filep, off_t length);
+  FAR void *(*mmap)(FAR struct file *filep, off_t start, size_t length);
+  int      (*munmap)(FAR struct task_group_s *group, FAR struct inode *inode,

Review Comment:
   Yes, agree. It is more flexible to pass the struct. I still left also the 
file pointer in the i_ops mmap call. It is something that might be needed in 
the mmap phase by the driver, but not supposed to be stored. Otherwise I think 
that my existing mm_map_entry_s matches quite well with your proposal, so I 
kept my own.
   
   



-- 
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: commits-unsubscr...@nuttx.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to