lkml.org 
[lkml]   [2000]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Imminent death of /proc/locks predicted; film at 11
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/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:3.280 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site