Messages in this thread |  | | Date | Mon, 12 Nov 2001 19:32:18 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [RFC][PATCH] VFS interface for extended attributes |
| |
On Mon, 12 Nov 2001, Andreas Gruenbacher wrote:
> There are curently two paths by which the extended attribute inode > operations can be invoked: (a) from a system call, (b) from the > permission() inode operation, when checking the access ACL of a file. We > could trivially use a dentry in (a), but unfortunately we don't have a > choice in (b), as permission() itself is not passed a dentry.
Which means that converting permission() to vfsmount/dentry should be done first. And that's not hard to do.
> > Rule of the tumb: if your function got a "cmd" argument - it's broken. > > ioctl(2). fcntl(2). prctl(2). quotactl(2). sysfs(2). Missed'em'V IPC > > syscalls. Enough, already. > > There is one difference between the interfaces you are complaining about > above and the proposed EA interface for EA's: In those interfaces you have > wildcard parameters that are used for who-knows-what, depending on a > command-like parameter, including use as a value, use as a pointer to a > value/struct, etc.
Yes, and? You've got more than enough material for the same kind of abuse. What's more, you _already_ have it - in some of the subfunctions *data is read from, in some - written to, in some - ignored. Worse yet, in some subfunctions we put structured data in there, in some - just a chunk of something.
With all that, who had said that a year down the road we won't get a dozen of new syscalls hiding behind that one?
Sorry, folks, but idea of private extendable syscall table (per-filesystem, no less) doesn't look like a good thing. That's _the_ reason why ioctl() is bad.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |