xiaoxiang781216 commented on PR #10602: URL: https://github.com/apache/nuttx/pull/10602#issuecomment-1720402119
> > > This case isn't suitable for stdio functions. How can you pass FILE * from one task/process to other task/process in kernel mode? So it's impossible to call the callback function cross the address space boundary since FILE* return from fopencookie can only be used by the caller's task/process and is always invalid and impossible to pass FILE* to another task/process at the first place. > > > > > > I don't see the relevance of the FILE*. I was more concerned at the io_funcs and cookie. But looking at the prototype, it seems impossible that the io_funcs could like in a different address space. from the caller of fopencookie(). > > Aggreed, it would require to pound defined and only allowing such APIs in usermode. Of course, all FILE functions can only be called inside the usermode, NuttX kernel forbid kernel code to use any FILE functions. > However, it could be doable by making a new vfs interface handling such but it would require a whole revamp and further thoughts to make it possible, as is : it is not hot patchable -> so my proposal to support indirection for user-mode build only, at least it can be undone and evolve without breaking. @mu578 you may misunderstand NuttX file system: - nuttx/fs/vfs is the kernel VFS infrastructure, which is part of kernel, it's hard and bad to call the callback provided by userspace - nuttx/libc/stdio is userspace library, which is very simple and common to call the callback provided by userspace > > That is impossible to callback from two distinct regions ; it would require some kind of trampoline jump with copies back and forth. E.g if `function pointers` were actually `just address pointers pointing to an actual somewhere` we would not have this conversation, but the reality is different. > Do you want to implement the userspace file system? NuttX already support it by message queue: https://github.com/apache/nuttx/blob/master/include/nuttx/fs/userfs.h > Myself, I would go to support standard only: `open_memstream` and `fmemopen` ; there is no reason to expose a non standard `fopencookie` call ; the two requires some memory mapping that's it, no callback exposure. It is all about to be able to use FILE api on a user in-memory buffer instead of on a `file descriptor/ino` ; which in case of nuttx is `kif-kif bourricot` a mere detail. If we want to support all open_memstream/open_wmemstream/fmemopen, it's important to setup a callback infrastructure otherwise fread/fwrite need add many: ``` if (file handle) { ... } else if (mem handle) { ... } else if (xxx handle) { ... } ``` -- 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
