lkml.org 
[lkml]   [2005]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Linux-cluster] Re: GFS, what's remaining
    Joel Becker <Joel.Becker@oracle.com> 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.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-09-04 10:23    [W:0.022 / U:2.336 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site