Re: [Announce] BKL shifting into drivers and filesystems - beware
[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)
[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