Lawrence D?Oliveiro <[email protected]> Wrote in message:r > On Tue, 17 Mar 2026 14:30:42 +0300, Oguz Kaan Ocal wrote:> Regarding the > linuxacl and linuxmount modules: how do you handle> compatibility across > different kernel versions? Since some of these> APIs (like Landlock or newer > mount features) are relatively recent,> does the library provide graceful > fallbacks or just raise> NotImplementedError?Landlock in particular has been > through about 7 versions so far, withsigns of an eighth on the way. I deal > with that by attach API versioninfo to the relevant enums.For example, if you > look at my Python version of the ?sandboxer?sample program in the Landlock > documentation, I get the API versionfrom the current kernel with > LL_VERSION = linuxpriv.get_landlock_version()then I can collect sets of > available access attributes with constructslike:* All read/write operations > on both files and directories: access_file_dir_rw = set \ ( > acc for acc in ACCESS_FS if acc.min_version <= LL_VERSION )* > Read-only operations on files: access_file_ro = set \ ( acc for acc in ACCESS_FS if acc.min_version <= LL_VERSION and acc.file_op and not acc.write_op )etc.As for libacl, I?m not aware of any API version changes -- not in theman pages I?ve been reading so far. Similarly the mount API -- both goso far back that I don?t think any kernels that don?t implement themare still in any kind of support. Correct me if I?m wrong. ;)> Using sets of enums instead of bitmasks is definitely 'The Pythonic> Way'. It makes the code much more self-documenting.More than that, I can attach extra attributes that can be used to easeprogramming, as in the examples above.
Thanks for the explanation, Lawrence. The way you?ve implemented the min_version attribute within the enums for Landlock is actually quite clever?it?s a clean way to handle the evolving nature of that API without cluttering the user-facing code. ?However, I have to push back a bit on your assumption regarding the mount API. While the legacy mount(2) system call is indeed a relic of the past, Linux introduced a completely New Mount API (starting with Kernel 5.2 in 2019) involving fsopen(), fspick(), fsmount(), and move_mount(). ?If your linuxmount module aims to be a comprehensive wrapper, ignoring these newer calls might be a missed opportunity. Conversely, if you are wrapping them, then the 'universal compatibility' you mentioned doesn't quite apply to older LTS kernels or enterprise environments that haven't migrated past 5.2 yet. In those cases, a simple NotImplementedError or an ENOSYS check would still be necessary. ?As for linuxacl, I agree?POSIX ACLs are stable enough that they?re practically part of the furniture at this point. ?The extra attributes like file_op and write_op are a great touch. It definitely saves the developer from having to keep a copy of the man pages open just to remember which bitmask does what. -- ----Android NewsGroup Reader---- https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html -- https://mail.python.org/mailman3//lists/python-list.python.org
