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

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


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 - 21:00:28 EST