yamt commented on PR #11724: URL: https://github.com/apache/nuttx/pull/11724#issuecomment-2116644633
> > > If you don't use file lock, could skip the local patch safely. > > > > > > it doesn't solve the maintenance problem. > > if no one wants to work on a solution, i'd suggest to revert it. > > This feature is used by other community member not us. It work fine, why do you want to revert it? because it's responsibility for the person adding a feature to find a maintainable implementation. my suggestion is * introduce an optional api to query filesystems file id usable for this purpose. say, F_GETIDFORLOCK * adapt this PR to use F_GETIDFORLOCK. when a filesystem doesn't support it, probably fall back to F_GETPATH. or just bail out with ENOTSUP or such. * revert F_GETPATH patch in littlefs because it seems unacceptable for the upstream. * add necessary api to the upstream littlefs, probably something along the line with: https://github.com/littlefs-project/littlefs/pull/976#issuecomment-2106900479. importantly we should provide something the upstream littlefs can accept. * implement F_GETIDFORLOCK in our littlefs driver, based on the new api. i guess you can iterate all open files and find aliases, and assign/reuse the in-core file id accordingly. alternatively, you can probably try to convince the littlefs author to accept [the get file path patch](https://github.com/littlefs-project/littlefs/pull/976). if it gets merged in the upstream, i have no big objection against having the patch in our tree for older littlefs versions in the meantime. i personally agree with his rationale of the rejection though. -- 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]
