From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99316 invoked by alias); 23 Nov 2016 15:52:06 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 99295 invoked by uid 89); 23 Nov 2016 15:52:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=assignments, Hx-spam-relays-external:sk:83-238-, H*RU:sk:83-238-, liberty X-HELO: smtpo49.poczta.onet.pl Received: from smtpo49.poczta.onet.pl (HELO smtpo49.poczta.onet.pl) (213.180.142.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Nov 2016 15:51:56 +0000 Received: from INFERNUS (83-238-224-194.adsl.inetia.pl [83.238.224.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: freddie_chopin@op.pl) by smtp.poczta.onet.pl (Onet) with ESMTPSA id 3tP6Js6m4FzStshqb for ; Wed, 23 Nov 2016 16:51:41 +0100 (CET) Message-ID: <1479916300.1135.1.camel@op.pl> Subject: Re: [PATCH, newlib] Allow locking routine to be retargeted From: Freddie Chopin To: newlib@sourceware.org Date: Wed, 23 Nov 2016 15:52:00 -0000 In-Reply-To: <7dc33ad1-fecf-a0ec-81b6-2db698c5c57d@foss.arm.com> References: <1478792031.1254.1.camel@op.pl> <60acaa10-fb22-8655-fd67-0536fe359871@foss.arm.com> <1478809956.1322.1.camel@gmail.com> <707976084.18201.1478865372907.JavaMail.zimbra@embedded-brains.de> <7dc33ad1-fecf-a0ec-81b6-2db698c5c57d@foss.arm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016/txt/msg01125.txt.bz2 Hi! I'm not Sebastian, but I took the liberty to give an opinion here. Option 1 brings almost nothing, as you have to make sure the toolchain you use supports the RTOS you want to use. If it doesn't you have to build your own. If you have to build your own, then you can as well just integrate locks without this change... As for the option 2 I guess that it would be perfectly reasonable to declare some kind of startup function that should be called by user's RTOS. I have just thought about another idea: 1. Newlib would define - in a public header - number of required recursive and non-recursive statically allocated locks: #define AMOUNT_OF_STATIC_LOCKS 5 #define AMOUNT_OF_STATIC_RECURSIVE_LOCKS 3 2. In the same header it would define functions like "void* get_lock(size_t index)" and "void* get_recursive_lock(size_t index)". 3. In some private newlib header there would be assignments of indexes with locks like: #define MALLOC_RECURSIVE_LOCK 0 #define STDIO_RECURSIVE_LOCK 1 ... #define TZ_LOCK 0 #define WHATEVER_LOCK 1 ... 4. All uses of locks like: __lock_acquire_recursive(__malloc_lock); would have to be changed to: __lock_acquire_recursive(get_recursive_lock(MALLOC_RECURSIVE_LOCK)); This way the user could just have in his own RTOS a nice array of locks with proper size and automatic amount of elements. More advantages: - by having two functions and two defines we could easily have recursive and non-recursive locks; - we could just drop __LOCK_INIT and add a requirement for user to initialize the locks; What do you think? Regards, FCh