ty den 09.08.2005 Klokka 08:47 (-0700) skreiv Bryan Henderson: > >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.
Have you looked at how we're dealing with this in NFSv4? Cheers, Trond - 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/
