On Sat, Sep 03, 2005 at 06:32:41PM -0700, Andrew Morton wrote:
> If there's duplicated code in there then we should seek to either make the
> code multi-purpose or place the common or reusable parts into a library
> somewhere.
Regarding sysfs and configfs, that's a whole 'nother
conversation. I've not yet come up with a function involved that is
identical, but that's a response here for another email.
Understanding that Daniel is talking about dlmfs, dlmfs is far
more similar to devptsfs, tmpfs, and even sockfs and pipefs than it is
to sysfs. I don't see him proposing that sockfs and devptsfs be folded
into sysfs.
dlmfs is *tiny*. The VFS interface is less than his claimed 500
lines of savings. The few VFS callbacks do nothing but call DLM
functions. You'd have to replace this VFS glue with sysfs glue, and
probably save very few lines of code.
In addition, sysfs cannot support the dlmfs model. In dlmfs,
mkdir(2) creates a directory representing a DLM domain and mknod(2)
creates the user representation of a lock. sysfs doesn't support
mkdir(2) or mknod(2) at all.
More than mkdir() and mknod(), however, dlmfs uses open(2) to
acquire locks from userspace. O_RDONLY acquires a shared read lock (PR
in VMS parlance). O_RDWR gets an exclusive lock (X). O_NONBLOCK is a
trylock. Here, dlmfs is using the VFS for complete lifetiming. A lock
is released via close(2). If a process dies, close(2) happens. In
other words, ->release() handles all the cleanup for normal and abnormal
termination.
sysfs does not allow hooking into ->open() or ->release(). So
this model, and the inherent lifetiming that comes with it, cannot be
used. If dlmfs was changed to use a less intuitive model that fits
sysfs, all the handling of lifetimes and cleanup would have to be added.
This would make it more complex, not less complex. It would give it a
larger code size, not a smaller one. In the end, it would be harder to
maintian, less intuitive to use, and larger.
Joel
--
"Anything that is too stupid to be spoken is sung."
- Voltaire
Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: joel.becker@xxxxxxxxxx
Phone: (650) 506-8127
--
Linux-cluster@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/linux-cluster
