From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3688 Path: news.gmane.org!not-for-mail From: Harald Becker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Current status: important changes since 0.9.11 Date: Fri, 19 Jul 2013 21:40:25 +0200 Message-ID: <20130719214025.7c8f2197@ralda.gmx.de> References: <20130719161234.GA8335@brightrain.aerifal.cx> <20130719203923.1a411332@ralda.gmx.de> <20130719185301.GJ12469@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1374262842 24721 80.91.229.3 (19 Jul 2013 19:40:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Jul 2013 19:40:42 +0000 (UTC) Cc: musl@lists.openwall.com, dalias@aerifal.cx Original-X-From: musl-return-3692-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 19 21:40:40 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1V0GXf-0007Rc-Bk for gllmg-musl@plane.gmane.org; Fri, 19 Jul 2013 21:40:39 +0200 Original-Received: (qmail 20102 invoked by uid 550); 19 Jul 2013 19:40:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20094 invoked from network); 19 Jul 2013 19:40:38 -0000 In-Reply-To: <20130719185301.GJ12469@brightrain.aerifal.cx> X-Provags-ID: V03:K0:ih/EzHXGYleCFQWVrC3kZA2mF3DlAYB8GjGoZLo27b0twVjRN6m DZWOe4+AUgeEBCIq0HH6h5jKOcmtXc9uY9AvB9SWWvAqgxvJY8sFc0ekxWxOqHOdgS8MTc5 PeNIBhZ+ls/WJYZEOaOEYIcHEvZznTe/255rlyMdrWe26/eSwmt3VWKLGSf0HHYB0UUe/uE 2M772NGTe1WrAcvjfJp9w== Xref: news.gmane.org gmane.linux.lib.musl.general:3688 Archived-At: Hi Rich! 19-07-2013 14:53 Rich Felker : > On Fri, Jul 19, 2013 at 08:39:23PM +0200, Harald Becker wrote: > 1. We already have "optimized asm" for a few archs, and I > didn't see a strong argument for removing it. The strong argument is single point of failure and equal startup on all plattforms. If you include the asm versions in main stream, nobody will use/test the new version on those systems. As soon as you decide to drop old code you stumble into the trouble, if such exist. Why not doing a careful and documented break (new startup) in next release. They should be compatible and tested for the main lines, so most people will not encounter problems. And those who catch trouble ... (see below) > 2. There's a chance to mess up odd arch-specific requirements, > alignment, etc. in the new asm fragment unless it undergoes > some careful review. Sure. That's the reason why I would include the old asm startup in the next release or the one there after, as (proposed) unmaintained code. If one stumbles into a rare corner case, which may be tracked down to the new startup files, it is possible to grab the old startup ... but you probably get early response of this, and may be able to fix new startup to handle things properly. As long as you get response to startup code, hold old asm versions in release for fallback usage. The relaese one version with proposed removal of old startup code, then drop it ... and you safe a lot of work on different places. Or do it in this way: Release one version with new old startup code as main stream and new one as alternative. Requesting testing, proposing switchover. If there is no response of startup code failures switch over to new startup on next release, with fallback to old asm version. This gives you an extra cycle/slot of testing, but rapid switch over and saving work for the future. -- Harald