Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> But what to do about DECLARE_MUTEX? :-/

A phased change of just the renames:
	DECLARE_MUTEX ==> DECLARE_SEM
	init_MUTEX ==> init_SEM
	DECLARE_MUTEX_LOCKED ==> DECLARE_SEM_LOCKED
	init_MUTEX_LOCKED ==> init_SEM_LOCKED

seems doable.  A scripted replacement, so long as it specifies whole
word replacement only, seems to be a very robust replacement for these
four symbols, unlike "up"/"down", which are scary at best to consider
wholesale replacement.

Add the new *_SEM in one release as aliases for the current *_MUTEX,
do the wholesale replacement of the above names, leaving the old as
aliases in a second release, remove the old *_MUTEX aliases in a third
release, and them restore them as new 'real mutex' methods in a fourth
release.  Be sure that the new *_MUTEX versions will generate a compile
error if handed the old counting semaphore type.

I'm a stickler for names ... at least until Linus/Andrew show me
the foolishness of my ways, I could find such a change appealing.

Of course, they're the ones with all the sweat equity on the line,
not me.

... I'd better duck and get back to bug fixing, before I get hit ...

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <[email protected]> 1.925.600.0401
-
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux