Re: [RFC] proposed libc interface and man page for listmount

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 6, 2023 at 4:38 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Tue, 5 Dec 2023 at 18:51, Matthew House <mattlloydhouse@xxxxxxxxx> wrote:
> > One use case I've been thinking of involves inspecting the mount list
> > between syscall(__NR_clone3) and _exit(), so it has to be async-signal-
> > safe. It would be nice if there were a libc wrapper that accepted a user-
> > provided buffer and was async-signal-safe, so that I wouldn't have to add
> > yet another syscall wrapper and redefine the kernel types just for this
> > use case. (I can't trust the libc not to make its own funny versions of the
> > types' layouts for its own ends.)
>
> You can just #include <linux/mount.h> directly.

The problem with including the <linux/*> headers is that they conflict with
the regular libc headers. So for instance, if I try to include both
<linux/mount.h> (for the listmount(2) kernel types) and <sys/mount.h> (for
the mount(2) and umount2(2) wrappers) on glibc, then I'll get a conflicting
definition for every single MS_* macro.

I suppose I could try to put all the listmount(2) stuff in a separate file,
but that would still require manual redefinitions of the listmount(2)
flags, unless I trusted libc to have its own identical redefinitions in
<sys/mount.h> or whatever header the wrapper would end up in, instead of
shuffling stuff around and translating it. Also, my current style in C is
to put all related code into a single file as possible, which this would
interfere with. At that point, I might as well redefine the whole thing.

Thank you,
Matthew House




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux