Joel Becker <Joel.Becker@xxxxxxxxxx> wrote:
>
> On Sun, Sep 04, 2005 at 12:28:28AM -0700, Andrew Morton wrote:
> > If there is already a richer interface into all this code (such as a
> > syscall one) and it's feasible to migrate the open() tricksies to that API
> > in the future if it all comes unstuck then OK.
> > That's why I asked (thus far unsuccessfully):
>
> I personally was under the impression that "syscalls are not
> to be added".
We add syscalls all the time. Whichever user<->kernel API is considered to
be most appropriate, use it.
> I'm also wary of the effort required to hook into process
> exit.
I'm not questioning the use of a filesystem. I'm questioning this
overloading of normal filesystem system calls. For example (and this is
just an example! there's also mknod, mkdir, O_RDWR, O_EXCL...) it would be
more usual to do
fd = open("/sys/whatever", ...);
err = sys_dlm_trylock(fd);
I guess your current implementation prevents /sys/whatever from ever
appearing if the trylock failed. Dunno if that's valuable.
> Not to mention all the lifetiming that has to be written again.
> On top of that, we lose our cute ability to shell script it. We
> find this very useful in testing, and think others would in practice.
>
> > Are you saying that the posix-file lookalike interface provides
> > access to part of the functionality, but there are other APIs which are
> > used to access the rest of the functionality? If so, what is that
> > interface, and why cannot that interface offer access to 100% of the
> > functionality, thus making the posix-file tricks unnecessary?
>
> I thought I stated this in my other email. We're not intending
> to extend dlmfs.
Famous last words ;)
> It pretty much covers the simple DLM usage required of
> a simple interface. The OCFS2 DLM does not provide any other
> functionality.
> If the OCFS2 DLM grew more functionality, or you consider the
> GFS2 DLM that already has it (and a less intuitive interface via sysfs
> IIRC), I would contend that dlmfs still has a place. It's simple to use
> and understand, and it's usable from shell scripts and other simple
> code.
(wonders how to do O_NONBLOCK from a script)
I don't buy the general "fs is nice because we can script it" argument,
really. You can just write a few simple applications which provide access
to the syscalls (or the fs!) and then write scripts around those.
Yes, you suddenly need to get a little tarball into users' hands and that's
a hassle. And I sometimes think we let this hassle guide kernel interfaces
(mutters something about /sbin/hotplug), and that's sad.
--
Linux-cluster@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/linux-cluster
