michallenc commented on PR #10602: URL: https://github.com/apache/nuttx/pull/10602#issuecomment-1720749268
To summarize the so far discussion a bit: The problem discussed here is a that this implementation reuses `file_operation_s` infrastructure which is a part of a file system (thus kernel address space) which is my fault as I haven´t realize during the implementation that the reuse of current infrastructure would lead to this. I quite like the proposition of reworked/new file system @mu578 suggested but as he mentioned, it is not a stuff for one patch and probably should be discussed on a mailing list first. I also do not agree with the statement > 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. as `fopencookie` can be beneficial for programmers (maybe even more than `fmemopen`). And while not being POSIX, we should keep in mind the NuttX compatibility with Linux imho. Also if done correctly, `fopencookie` can be used both as libc call available for programmers and internal hook for `fopencookie` and `open_memstream`. Regarding kernel protected builds, address space (and also priorities to keep strict scheduling), I think it should be sufficient to ensure user calls read/write/seek/close do not enter kernel space i.e. `fs/vfs` when used with `fopencookie`. In that case all code would remain in stdio libc library and would be purely user space therefore none of the mentioned issues should occur. I would go with @xiaoxiang781216 suggested implementation for that and we will see where it leads. -- 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
