Martin Kletzander wrote: > >That's an interesting question. > > > >A check for sys/mount.h was added with the initial implementation of the > >mount() using code in commit 1da631e. The mount() call currently is used > >only on platforms with cgroups available (i.e. Linux). > > > >Moreover, HAVE_SYS_MOUNT_H does not play any role in cgroups detection: > > > >#if defined(__linux__) && defined(HAVE_GETMNTENT_R) && \ > > defined(_DIRENT_HAVE_D_TYPE) && defined(_SC_CLK_TCK) > ># define VIR_CGROUP_SUPPORTED > >#endif > > > >So, sys/mount.h and mount() are only needed on Linux anyway, and I'm > >wondering if we actually can just do something like this: > > > >#if defined HAVE_SYS_MOUNT_H && defined HAVE_GETMNTENT_R > ># include <sys/mount.h> > >#endif > > > >as if we don't have HAVE_GETMNTENT_R define, we will not have > >VIR_CGROUP_SUPPORTED, and therefore we'll not need the mount() call. > > > > That's true. While modifying this in my local tree I took it a little > bit further in my head. First I thought why don't we include the header > just above the VIR_CGROUP_SUPPORTED definition. Then I thought, hy why > don't we include everything that we can there (just to get rid of future > mistakes like this one with mount). And then I figured that we could > split those two cgroup "implementations" > > >I've tested it on FreeBSD and OpenBSD and it builds fine. Unfortunately, > >cannot test it on Linux at this moment. > > > > Moreove the mount() calls that are there are only used for LXC. Anyway, > I tested both your approach and also including the file only around the > definition of VIR_CGROUP_SUPPORTED (guarded with the HAVE_SYS_MOUNT_H of > course) and it worked. But I wonder why we chose to implement cgroups > in one file and not split it into two so that we don't have to deal with > include issues if building without cgroups. Having said that, I don't > know what's the preferred way, but now it looks like splitting into > multiple files (instead of #ifdef guarding) seems better, at least to me. AFAIR I touched this code maybe 2 years ago or so to make stuff easier to maintain for platforms without cgroups support and I remember also Eric Blake helped a lot with that. I don't remember if it was discussed to have a separate file for stubs though. Anyway, it seems that the header issue is the only inconvenience caused by the current approach. Otherwise it feels OK to be able to add new functions and the corresponding stubs in scope of a single file. Considering that it's very unlikely that there will be some other real implementation but Linux one, probably it's fine as it is (though I don't touch cgroups related code often, so my opinion could be biased). Roman Bogorodskiy -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list