On Mon, Jan 25, 2021 at 04:45:07PM +0100, Jan Kara wrote: > On Mon 25-01-21 09:38:54, Sascha Hauer wrote: > > On Fri, Jan 22, 2021 at 05:16:58PM +0000, Christoph Hellwig wrote: > > > On Fri, Jan 22, 2021 at 04:15:29PM +0100, Sascha Hauer wrote: > > > > This patch introduces the Q_PATH flag to the quotactl cmd argument. > > > > When given, the path given in the special argument to quotactl will > > > > be the mount path where the filesystem is mounted, instead of a path > > > > to the block device. > > > > This is necessary for filesystems which do not have a block device as > > > > backing store. Particularly this is done for upcoming UBIFS support. > > > > > > > > Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> > > > > > > I hate overloading quotactl even more. Why not add a new quotactl_path > > > syscall instead? > > > > We can probably do that. Honza, what do you think? > > Hum, yes, probably it would be cleaner to add a new syscall for this so > that we don't overload quotactl(2). I just didn't think of this. How should the semantics of that new syscall look like? The easiest and most obvious way would be to do it like the quotactl(2) and just replace the special argument with a path: int quotactl_path(int cmd, const char *path, int id, caddr_t addr); If we try adding a new syscall then we could completely redefine the API and avoid the shortcomings of the original quotactl(2) if there are any. Can you foresee the discussions we end up in? I am afraid I am opening a can of worms here. OTOH there might be value in keeping the new syscall compatible to the existing one, but I don't know how much this argument counts. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
