On Fri, Jan 20, 2012 at 16:57, Roger Leigh <rleigh@xxxxxxxxxxxxx> wrote: > On Fri, Jan 20, 2012 at 03:56:43PM +0100, Kay Sievers wrote: >> On Fri, Jan 20, 2012 at 15:20, Masatake YAMATO <yamato@xxxxxxxxxx> wrote: >> >> >> >> I'd like to add support for /etc/fstab.d to libmount. The library is >> >> currently used by mount, umount and mount.nfs. The goal is to use it >> >> on more places. >> > >> > I'm working on systemd to support /etc/fstab.d. >> >> It's an old glibc API, and /etc/fstab is ABI, not a service config >> file, which now can read more than one file. It's a very different >> problem. It an ABI change, not a config extension. > > I think that's putting the problem a little too strongly. The > glibc API is generic: it can (and is) used to parse any file using > the fstab(5) file format; it's not restricted to only /etc/mtab > and /etc/fstab. setmntent(3) accepts any filename. That's right, but it's just not the way it's used. None of the old tools is prepared to just wrap that in a readdir() loop. > You are entirely correct that it may break the assumptions made by > some software, but it's certainly not "ABI" or even "API" breakage. It is surely the de-facto Linux/UNIX ABI for system mounts. >> Tools rightfully expect that they find all system mounts in that file, >> and not in some new split-up directory. In some cases, fstab is used >> to 'check if the device is not a system volume', and that will just >> break now, > > The number of tools which do this is tiny, and could (if we wished) > be patched trivially to also look at the files in fstab.d. > > Alternatively, glibc itself could be updated so that if e.g. > setmntent(3) is called with "/etc/fstab" as its filename argument, > it will additionally process and include the contents of > /etc/fstab.d as well. This would have the advantage of transparency > for all users of the glibc interface. That's true, but good luck with glibc changes. :) Kay -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
