W-M-R opened a new pull request, #18316: URL: https://github.com/apache/nuttx/pull/18316
Summary This change adds seek function support to the [mem](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html) driver and refactors how file position is tracked during read/write operations. Key changes: Added devmem_seek() function: Implements standard seek operation with support for SEEK_SET, SEEK_CUR, and SEEK_END positioning modes Changed position tracking semantics: Modified filep->f_pos to store the offset within the memory region rather than absolute memory addresses Updated read/write logic: Changed from using filep->f_pos as an absolute address to calculating actual memory addresses by adding the offset to region[i].start Why this is necessary: Previously, filep->f_pos was being used to store absolute memory addresses, which is semantically incorrect and prevented proper seek operations Users couldn't use standard file operations like lseek() to navigate within [mem](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html) The new approach aligns with standard POSIX file semantics where f_pos represents an offset from the beginning of the file Impact Users: Applications can now use lseek() to position within [mem](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html) before reading or writing Behavior of sequential read/write operations remains unchanged More intuitive offset-based positioning instead of absolute address manipulation Compatibility: Existing code that only performs sequential read/write operations will continue to work without modification Code that directly manipulated f_pos as an absolute address may need updates Build process: No changes to build process or dependencies Security: Maintains existing permission checks (PROT_READ/PROT_WRITE flags) Validates offset boundaries to prevent out-of-range access Testing Test Platform: File: [dev_mem.c](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html) Changed: 1 file, +45 insertions, -7 deletions Test Cases: Sequential read/write: Verified existing behavior works correctly Open [mem](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html) and perform consecutive reads/writes Confirmed f_pos advances correctly after each operation Seek operations: Tested all seek modes SEEK_SET: Position to absolute offset from region start SEEK_CUR: Relative positioning from current position SEEK_END: Position relative to end of all memory regions Verified negative offsets are rejected with -EINVAL Boundary checking: Confirmed operations respect memory region boundaries Attempts to read/write beyond valid regions return -EINVAL Offset calculations correctly use region[i].start + filep->f_pos Permission enforcement: Verified PROT_READ/PROT_WRITE flags are still honored Expected behavior verified: ✅ Seek function returns current position on success ✅ Read/write operations use offset-based addressing ✅ File position tracks offset within region, not absolute address ✅ All seek modes (SET/CUR/END) function correctly ✅ Invalid offsets rejected appropriately -- 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]
