On Tue, Nov 28, 2006 at 05:54:28AM +0000, Christoph Hellwig wrote:
> What crack do you guys have been smoking?
I'd like to apologize for this statement, it was a little harsh.
I still think most of these APIs are rather braindead, but then again
everyone does braindead APIs from now to then.
I still think it's very futile that you try to force APIs using
standizations on us. Instead of going down that route please try
to present a case for every single API you want, including reasonings
why this can't be fixed by speeding up existing APIs. Note that with
us I don't mean just linux but also other OpenSource OSes. Unless you
at least get Linux and FreeBSD and Solaris to agree on the need for
the API it's very pointless to go anywhere close to a standization body.
Anyway, let's go on to the individual API groups:
- readdirplus
This one is completely unneeded as a kernel API. Doing readdir
plus calls on the wire makes a lot of sense and we already do
that for NFSv3+. Doing this at the syscall layer just means
kernel bloat - syscalls are very cheap.
- lockg
I'm more than unhappy to add new kernel-level file locking calls.
The whole mess of lockf vs fcntl vs leases is bad enough that we
don't want to add more to it. Doing some form of advisory locks
that can be implemented in userland using a shared memory region
or message passing might be fine.
- openg/sutoc
No way. We already have a very nice file descriptor abstraction.
You can pass file descriptors over unix sockets just fine.
- NFSV4acls
These have nothing to do at all with I/O performance. They're
also sufficiently braindead. Even if you still want to push for
it you shouldn't mix it up with anything else in here.
- statlite
The concept generally makes sense. The specified details are however
very wrong. Any statlite call should operate on the normal
OS-specified stat structure and have the mask of flags as an
additional argument. Because of that you can only specific
existing posix stat values as mandatory, but we should have an
informal agreement that assigns unique mask values to extensions.
This allows applications to easily fall back to stat on operating
systems not supporting the flags variant, and also allows new
operating systems to implement stat using the flags variant.
While we're at it statlight is a really bad name for this API,
following that *at APIs it should probably be {l,f,}statf.
- O_LAZY
This might make some sense. I'd rather implement lazyio_synchronize
and lazyio_propagate as additional arguments to posix_fadvise, though.
- readx/writex
Again, useless bloat. Syscalls are cheap, and if you really want
to submit multiple s/g I/Os at the same time and wait for all of
them use the Posix AIO APIs or something like Linux's io_submit.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
