gh-99987: fcntl add the F_KINFO constant for FreeBSD 13.1 and onwards.#99988
gh-99987: fcntl add the F_KINFO constant for FreeBSD 13.1 and onwards.#99988devnexen wants to merge 3 commits intopython:mainfrom
F_KINFO constant for FreeBSD 13.1 and onwards.#99988Conversation
serhiy-storchaka
left a comment
There was a problem hiding this comment.
fcntl() does not contain code specific to other operations. The user is expected to provide a buffer object of the correct size and properly initialized.
d778702 to
af9ce0d
Compare
e060767 to
ed72a9b
Compare
- removing custom code out of `fcntl.fcntl`. - F_GETPATH requires MAXPATHLEN or greater so we increase the buffer size to be able to cater with F_KINFO greater size. - `fcntl.kinfoalloc` preallocate a proper kinfo_file buffer. - `fcntl.kinfodict` returns a handy representation of the data.
ed72a9b to
efafa69
Compare
serhiy-storchaka
left a comment
There was a problem hiding this comment.
I understand why do you want to add kinfoalloc() and kinfodict(), but for now there are no precedents for other operations. See for example the use of F_SETLK in tests and in third-party examples. They use struct.pack() and struct.unpack(). The format string, unfortunately, is platform depending.
If we came with better solution, it should be universal, and cover all other fcntl() and ioctl() operations. It is a different and much larger issue. Let limit this issue for adding F_KINFO (and maybe other constants?).
| ``FICLONERANGE`` constants, which allow to share some data of one file with | ||
| another file by reflinking on some filesystems (e.g., btrfs, OCFS2, and | ||
| XFS). This behavior is commonly referred to as "copy-on-write". | ||
| On FreeBSD >= 13.1, the :mod:`fcntl` module exposes the ``F_KINFO`` |
There was a problem hiding this comment.
It should be versionchanged:: 3.13 now.
|
|
Oh, nested unions in the middle of structure. They hate us. It means also that the complete unpacker that supports all fields should be super complex. Does it support binary compatibility with FreeBSD < 12? If yes, then the first element in the union should have the largest size, and we can ignore alternatives. |
|
That makes it more user unfriendly tough, the user needs to be aware of the struct layout (which might evolve over versions), pack() implies initialises fields which we do not want to do but one ... etc. Here an example of the format |
F_KINFOconstant for FreeBSD (from 13.1 release) #99987