On Sun, Sep 04, 2005 at 12:23:43AM -0700, Andrew Morton wrote: > > What would be an acceptable replacement? I admit that O_NONBLOCK -> trylock > > is a bit unfortunate, but really it just needs a bit to express that - > > nobody over here cares what it's called. > > The whole idea of reinterpreting file operations to mean something utterly > different just seems inappropriate to me. Putting aside trylock for a minute, I'm not sure how utterly different the operations are. You create a lock resource by creating a file named after it. You get a lock (fd) at read or write level on the resource by calling open(2) with the appropriate mode (O_RDONLY, O_WRONLY/O_RDWR). Now that we've got an fd, lock value blocks are naturally represented as file data which can be read(2) or written(2). Close(2) drops the lock. A really trivial usage example from shell: node1$ echo "hello world" > mylock node2$ cat mylock hello world I could always give a more useful one after I get some sleep :) > You get a lot of goodies when using a filesystem - the ability for > unrelated processes to look things up, resource release on exit(), etc. If > those features are valuable in the ocfs2 context then fine. Right, they certainly are and I think Joel, in another e-mail on this thread, explained well the advantages of using a filesystem. > But I'd have thought that it would be saner and more extensible to add new > syscalls (perhaps taking fd's) rather than overloading the open() mode in > this manner. The idea behind dlmfs was to very simply export a small set of cluster dlm operations to userspace. Given that goal, I felt that a whole set of system calls would have been overkill. That said, I think perhaps I should clarify that I don't intend dlmfs to become _the_ userspace dlm api, just a simple and (imho) intuitive one which could be trivially accessed from any software which just knows how to read and write files. --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@xxxxxxxxxx -- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
