From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 13 Dec 2005 10:34:27 +0100 From: Ingo Molnar Subject: Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation Message-ID: <20051213093427.GA26097@elte.hu> References: <20051212161944.3185a3f9.akpm@osdl.org> <20051213075441.GB6765@elte.hu> <1134460804.2866.17.camel@laptopd505.fenrus.org> <20051213090349.GE10088@elte.hu> <20051213090917.GC15804@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051213090917.GC15804@wotan.suse.de> To: Andi Kleen Cc: Arjan van de Ven , Andrew Morton , David Howells , torvalds@osdl.org, hch@infradead.org, matthew@wil.cx, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org List-ID: * Andi Kleen wrote: > > it's not _that_ bad, if done overnight. It does not touch any of the > > down/up APIs. Touching those would create a monster patch and monster > > impact. > > One argument for a full rename (and abandoning the old "struct > semaphore" name completely) would be that it would offer a clean break > for out tree code, no silent breakage. yeah. Another way to handle it would be to keep 'struct semaphore' for the traditional semaphore type (together with the APIs), and to mark them deprecated. I.e. we'd have 3 separate types and 3 separate sets of APIs: 'struct mutex' & APIs 'struct semaphore' & APIs 'struct compat_semaphore' & APIs phase #1: we do an overnight rename to 'struct mutex' and to 'struct compat_semaphore', based on the info that has been mapped by the -rt tree. We mark 'struct semaphore' deprecated. phase #2: we let out-of-tree code still work that uses struct semaphore, but for new code applied, it must not be used. phase #3: we remove 'struct semaphore' and APIs. the problem with this approach is that it touches the semaphore APIs too, which increases the impact of the rename by a _factor of 10_. Right now we have ~600 places that use 'struct semaphore', but we have over 7000 places that use the APIs! I dont think it's realistic to do an overnight change of all the APIs, we'd break every out-of-kernel tree in a massive way. (the type change alone is much more manageable) Ingo