Re: [RFC] Imminent death of /proc/locks predicted; film at 11

From: Matthew Wilcox (matthew@wil.cx)
Date: Sat Sep 30 2000 - 19:34:35 EDT

  • Next message: Andre Hedrick: "Re: [PATCH] Fix for I-Opener IDE problems"

    On Sun, Oct 01, 2000 at 12:29:27AM +0100, Alan Cox wrote:
    > > Does anyone actually want /proc/locks to stay? The data structure
    >
    > I'd like a way to view the locks that exist - its useful for debugging
    > weird app stuff
    >
    > > out /proc/locks. If it could be deleted, a lot of code and data pointers
    > > could go away. I don't think any program depends on its existance and
    > > it's a pretty ugly file anyway (exposing kernel pointers to userspace?
    > > looks like pure debug code).
    > >
    > > Speak now, or it shall be gone.
    >
    > If it makes the code far cleaner then I have no objection. If we can do a
    > simple (different format even) /proc/locks to replace it that scores double
    > points ;)

    This was the sort of objection I was hoping to receive :-)

    When debugging this kind of problem, you're not interested in the
    non-conflicting locks, only the ones which are blocked waiting for
    another lock, right?

    If so, then we need that structure around anyway for doing the crappy
    POSIX deadlock detection. And I don't have a problem with exposing that
    to userspace.

    If you did want all locks, we could walk all inodes in core and print
    out all the locks held on them :-) That might even be more scalable than
    the current approach... 

    -- 
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

    This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 19:37:29 EDT