From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28477 invoked by alias); 2 Apr 2008 14:52:04 -0000 Received: (qmail 28466 invoked by uid 22791); 2 Apr 2008 14:52:03 -0000 X-Spam-Check-By: sourceware.org Received: from mgcp1.bloomberg.com (HELO mgcp1.bloomberg.com) (208.22.56.39) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Apr 2008 14:51:46 +0000 Received: from ny2570.bloomberg.com ([172.20.72.138]) by mgcp1.bloomberg.com with ESMTP; 02 Apr 2008 10:51:44 -0400 Received: from ny2528.corp.bloomberg.com (ny2528.corp.bloomberg.com [172.20.85.39]) by ny2570.bloomberg.com (8.14.1/8.14.1) with ESMTP id m32EpbNO024266; Wed, 2 Apr 2008 10:51:37 -0400 Received: from ny2545.corp.bloomberg.com ([172.20.73.98]) by ny2528.corp.bloomberg.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 10:51:37 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 02 Apr 2008 14:52:00 -0000 Message-ID: In-Reply-To: <47F39605.8070605@eCosCentric.com> References: <20080326180616.GA5705@lunn.ch> <20080326181817.GB5705@lunn.ch> <20080326183202.GC5705@lunn.ch> <20080326185037.GD5705@lunn.ch> <47F39605.8070605@eCosCentric.com> From: "Chris Zimman" To: "Jonathan Larmour" Cc: X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] ARM EABI port / static constructor priority removal X-SW-Source: 2008-04/txt/msg00010.txt.bz2 > And also needs to be run _after_ the kernel code, but potentially > before the libc code (which may reference the RTC), etc.etc. It's just n= ot > feasible while retaining modularity which is far more valuable. If it were written in C, there's still a way to do it, and it doesn't requi= re static constructor init ordering. =20 > Not really. In cyg_type.h CYG_INIT_APPLICATION is defined, and > priorities > 60000 up to 65534 are free for application use. >=20 > Arguably not with a reserved range for application use. What if your code needs to do something in between one of the OS startup steps? This statement makes the assumption that the application and kernel code are really separate, which is sometimes not a very clearly defined line in eCos. Presumably, one could argue that you shouldn't be doing anything outside of the 'allowed' range by definition, but see next section... > It's potentially feasible to create a section (not .ctors, something > eCos-specific) that contains a list of tuples - a priority number and a > function pointer. But then a) the list needs to be sorted at runtime > which > is very bad; and b) it seems very much that we're just swapping one > extension for another. Or they could be a set of ordered singletons in a startup file or something equivalent. Of course, this precludes one from writing a driver outside of the tree and having it called in between steps. =20 > It's not the best solution, but it may be the least worst. I guess it depends on how much one considers relying on non-portable compil= er specific behavior bad or not. It's not part of ARM EABI officially, and had CodeSourcery not decided to implement it, I would've had to do something different to get EABI to work. My point is not that it doesn't work as is, but rather, that it's a self imposed limitation that there are portable ways to solve. If no one else wants to pursue it, I have to leave it as is though. --Chris -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss