Jody McIntyre <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 10, 2005 at 08:55:03PM -0800, Andrew Morton wrote: > > Jody McIntyre <[EMAIL PROTECTED]> wrote: > > > > > > parisc and frv define sem_getcount() in semaphore.h, which returns the > > > current semaphore value. This is cleaner than doing > > > atomic_read(&semaphore.count), currently done in > > > drivers/ieee1394/nodemgr.c and fs/xfs/linux-2.6/xfs_buf.c, and will work > > > on all architectures if sem_getcount() is added. > > > > That's a fairly bizarre thing to want to do. Would it be hard to modify > > xfs and 1394 to stop wanting to read a semaphore's up() count? > > The count is the number of free transaction labels (1394 async is > transaction-based) and is initialized to 64. When a new transaction label > is needed, the requestor does a down(), then locks the tlabel variables > and allocates a new one. When a transaction label is freed, an up() > occurs. The semaphore's up() count is therefore the number of free > tlabels, and the number of outstanding transactions is (64 - count). I > can imagine situations in which this would be a useful statistic, but > I'm not sure any of them actually exist.
That's a nice application of semaphores. I can see that there's also a need to be able to read the value back for reporting purposes. Dang. But I guess it's a bit hard to justify adding more infrastructure to support a single callsite which has a simple alternative. So if you could please add the separate counter? > ... > > If this patch isn't accepted, we should get rid of the xfs and 1394 > hacks and delete sem_getcount (parisc, frv) and sema_count (arm) as they > are unused. True. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/