Re: [Announce] BKL shifting into drivers and filesystems - beware

2000-07-14 Thread David Woodhouse


[EMAIL PROTECTED] said:
> David Woodhouse wrote:
> > Can we now remove sleep_on() completely, or at least apply something
> > like the following:

> > if (current->lock_depth == -1) BUG();

> That won't work.

> 1) lock_depth is only updated on SMP. 

But it would still highlight the problem on SMP builds. It only needs to be
fixed once. Consider it a similar hack to slab poisoning or spinlock
debugging.

> 2) the global cli spinlock is the second valid lock for sleep_on() users.

Personally, I don't mind if we break a few valid uses to make sure we 
flush all the broken ones. And the operative word there is 'few'.

> And sleep_on a very good litmus test for SMP awareness: grep for
> sleep_on, and if you find it it's a good sign that the driver is not
> SMP aware ;) 

hehe true. Let's just remove it altogether then.



--
dwmw2





Re: Can't hardlink in different dirs. (BUG#826)

1999-12-03 Thread David Woodhouse


[EMAIL PROTECTED] said:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
> > [..] I can definately say that making hardlinks to files in other
> > directories (not owned by the linking user) is a handy feature. [..]

> For what exactly is it an handy feature? I never needed to hardlink to
> a file that I don't own, so you would convince me if you would raise
> good points.

ISTR I used to (want to?) do this a lot when I had to use boxen I didn't have
root on, especially Solaris boxen which had nothing useful installed by
default.

If someone had already compiled for themselves a copy of whatever program I 
wanted, I prefer to hard link it than symlink it because that way it doesn't 
disappear when they have finished with it, or when their account is removed.



--
dwmw2