new stat*fs-like syscall?
in [Kernel]
|
Prev: [PATCH] tps65023: Allow registering similar TPS65021
Next: [PATCH] video: simplify strlen()==0 check in fb_get_options()
From: Brad Boyer on 5 Jul 2010 17:50 On Sat, Jun 26, 2010 at 09:54:44PM +0900, J. R. Okajima wrote: > Christoph Hellwig: > > That's really job for a pathconf system call that allows quering random > > paramters. > > Do you mean it should be implemented such like this? > vfs_pathconf(struct dentry, int parm) > --> return d_sb->s_op->pathconf(parm) I would suggest making it an inode operation if we do actually add it. Most cases are going to be per super-block, but it might be easier to transparently handle things like _PC_PIPE_BUF in glibc if it could call an fpathconf type system call on the pipe fd. I haven't looked at the current glibc code for that particular selector. The only one I looked at in any detail was _PC_LINK_MAX, which is the one you already discussed and is obviously a per-sb option. The only drawback I can see is that making it an inode operation would make the vfs_pathconf fail on a negative dentry, but that seems like a very strange thing to support in any case. > I am afraid it is overdesign because the actual parameter(for FS) is > _PC_LINK_MAX only. All other params are already handled by VFS, glibc or > sb->statfs. Brad Boyer flar(a)allandria.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: J. R. Okajima on 5 Jul 2010 19:40 Brad Boyer: > I would suggest making it an inode operation if we do actually add it. Most > cases are going to be per super-block, but it might be easier to transparently > handle things like _PC_PIPE_BUF in glibc if it could call an fpathconf type > system call on the pipe fd. I haven't looked at the current glibc code for > that particular selector. The only one I looked at in any detail was > _PC_LINK_MAX, which is the one you already discussed and is obviously a > per-sb option. The only drawback I can see is that making it an inode > operation would make the vfs_pathconf fail on a negative dentry, but that > seems like a very strange thing to support in any case. Recently the size of the pipe buffer becomes customizable, doesn't it? For _PC_PIPE_BUF, fpathconf should issue fcntl(F_GETPIPE_SZ). For negative dentry, it should be supported as long as some standard/specification doesn't prohibit explicitly. So I still think statfs is the best place to implement _PC_LINK_MAX. J. R. Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Brad Boyer on 5 Jul 2010 20:50 On Tue, Jul 06, 2010 at 08:31:30AM +0900, J. R. Okajima wrote: > Recently the size of the pipe buffer becomes customizable, doesn't it? > For _PC_PIPE_BUF, fpathconf should issue fcntl(F_GETPIPE_SZ). That should work and is in line with my understanding of the current code for pathconf in glibc. > For negative dentry, it should be supported as long as some > standard/specification doesn't prohibit explicitly. So I still think > statfs is the best place to implement _PC_LINK_MAX. If we're going to be changing statfs (or adding a new system call) anyway, that does seem like a reasonable place to export this data along with whatever else gets added. With the various things that have been suggested, maybe we need something more like the stat replacement that has been getting discussed with the room for some larger optional fields and a way to request a specific set of fields. Brad Boyer flar(a)allandria.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 6 Jul 2010 12:50 On Mon, Jul 5, 2010 at 5:45 PM, Brad Boyer <flar(a)allandria.com> wrote: > On Tue, Jul 06, 2010 at 08:31:30AM +0900, J. R. Okajima wrote: >> For negative dentry, it should be supported as long as some >> standard/specification doesn't prohibit explicitly. So I still think >> statfs is the best place to implement _PC_LINK_MAX. > > If we're going to be changing statfs (or adding a new system call) > anyway, that does seem like a reasonable place to export this data > along with whatever else gets added. With the various things that > have been suggested, maybe we need something more like the stat > replacement that has been getting discussed with the room for some > larger optional fields and a way to request a specific set of fields. Let's not overdesign things. Just do something like the attached patch, which is the obvious and straightforward thing to do. Overdesigning is a disease. It's fundamentally wrong. (Yeah, yeah,. the patch is untested, and doesn't actually _fill_ the new f_flags value, but that's left as a trivial exercise for the reader.) Linus
From: Christoph Hellwig on 6 Jul 2010 21:50
On Tue, Jul 06, 2010 at 09:45:26AM -0700, Linus Torvalds wrote: > Let's not overdesign things. Just do something like the attached > patch, which is the obvious and straightforward thing to do. > > Overdesigning is a disease. It's fundamentally wrong. > > (Yeah, yeah,. the patch is untested, and doesn't actually _fill_ the > new f_flags value, but that's left as a trivial exercise for the > reader.) At least one of the readers posted a patch filling it in already. Need to send out the version with the review comments addressed, but I'm still waiting for Uli if he really insists on new syscall vectors for the same structure. Using that one ST_VALID bit seems a lot easier to me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |