From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <530CDCD3.6070703@xenomai.org> Date: Tue, 25 Feb 2014 19:11:31 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <530CD8B9.2010303@xenomai.org> In-Reply-To: <530CD8B9.2010303@xenomai.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Road to 3.0 List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: "Kiszka, Jan" , "Xenomai@xenomai.org" On 02/25/2014 06:54 PM, Philippe Gerum wrote: > > Hi, > > This is the remaining work toward 3.0 from my perspective. Please > comment, amend, extend or shatter as needed. > > - RTDM > * decide and freeze API changes. > * the native implementation may need some care and testing, we never > had any feedback for this code. > * fixup of in-tree drivers for API changes > > - Analogy > * comedi drivers still in the staging tree for mainline vs porting the > Analogy framework over the mercury core. > > - Alchemy needs more test cases, although all core features are covered > by at least one test already - except messages pipes. This latter > interface is now a plain wrapper on top of rtipc/xddp though. > > - Documentation > * the inline documentation for the Cobalt kernel was amended gradually > as development took place, but we still have a general review and > cleanup duties ahead for this material. We need to reintroduce the posix services documentation, likely moving it as doxygen documentation in lib/* rather than in the kernel-space code as it was in 2.x. Not at a high priority since the posix API is documented elsewhere, the only interest in having a documentation is to document the behaviours which are unspecified (or non-conformant). > * Copperplate is not documented yet. Only API designers would need this > though. > * User guide for 3.x. > * Review, fixup of the new migration and installation guides. > * website updates for 3.x. We may want to fork the documentation area > in two distinct zones, for 2.x and 3.x, otherwise I suspect that many > people will get utterly confused. The API documentation already lives in a per-version directory on the server. README.INSTALL, TROUBLESHOOTING and manual pages link directly to 2.6 documentation. > > - /proc/xenomai refactoring for Cobalt. With most APIs now implemented > in userland and the introduction of the new fuse-based registry, > /proc/xenomai/registry does not contain much these days. In fact, only > the RTIPC drivers can still create links there. > > It boils down to this question: will the POSIX core introduce new > registry files, or will RTDM-based code remain the only in-kernel > registry user? I was planning to work on this, I even had some stuff started in a corner of my HDD. I would like to add registry files for all the POSIX skin objects, including anonymous ones (such as mutex and condvars). And use the information in /proc to make a user-space deadlock debugger. This is not high priority stuff. > > - I pulled out the examples area during the early development days, it > is time to push some demo code back in, preferably that would work over > both Cobalt and Mercury cores indifferently. > > - nios2 and sh4 over Cobalt are lagging behind, basically because we > would need a 3.10+ reference kernel for implementing the proper pipeline > bits 3.x requires, which we don't have. I'll be looking for such kernel > for supporting nios2 at some point. I'm unsure for sh4: no hardware at > hand, and most importantly, nobody seemed to care about running Xenomai > over this architecture. > > - running the Copperplate layer over uClibc instead of glibc. Last time > I tried (a couple of years ago), several nightmare-class issues popped > up. The question is: do we still need this, is it worth the effort, or > can we reasonably make glibc a pre-requisite for running non-POSIX APIs > in dual kernel (i.e. Cobalt) mode? Blackfin and nios2 were the primary > users of Xenomai's uClibc compatibility in 2.x. > > - any change that would be pending to the pipeline core API. If you have > any brewing or to be suggested, now is a good time to speak up. Nothing on my side except ipipe_smp_p introduced by latest patches. > > - The vrtx and uITRON APIs have not been rewritten over the copperplate > layer yet. Given that we received no valuable feedback over the years > for these skins, I don't see the point in implementing this today. > > - Finally, I have a series of 130+ specific implementation > changes/issues for the -forge tree pending in my todo list. Nothing > really bad or difficult, only a truckload of details. > > I'm refraining from indicating any priority for these tasks, since this > should be part of the discussion. A distinction between what's available > for the first candidate release and the final one may make sense. I have no preference for the priorities. -- Gilles.