>Intents are meant as optimisations, not replacements for existing
>operations. I'm therefore not really comfortable about having them
>return errors at all.
That's true of normal intents, but not what are called intents here. A
normal intent merely expresses an intent, and it can be totally ignored
without harm to correctness. But these "intents" were designed to be
responded to by actually performing the foreshadowed operation now -
irreversibly.
Linux needs an atomic lookup/open/create in order to participate in a
shared filesystem and provide a POSIX interface (where shared filesystem
means a filesystem that is simultaneously accessed by something besides
the Linux system in question). Some operating systems do this simply with
a VFS lookup/open/create function. Linux does it with this intents
interface.
It's hard to merge the concepts in code or in one's mind, which is why
we're here now. A filesystem driver that needs to do atomic
lookup/open/create has to bend over backwards to split the operation
across the three filesystem driver calls that Linux wants to make.
I've always preferred just to have a new inode operation for
lookup/open/create (mirroring the POSIX open operation, used for all opens
if available), but if enough arguments to lookup can do it, that's
practically as good. But that means returning final status from lookup,
and not under any circumstance proceeding to create or open when the
filesystem driver has said the entire operation is complete.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |