From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4AC36ACA.8080201@domain.hid> Date: Wed, 30 Sep 2009 16:27:22 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4AC2448B.1080500@domain.hid> <634c78ce0909300710i6d30b905kafdf7d76b2b31c7c@domain.hid> In-Reply-To: <634c78ce0909300710i6d30b905kafdf7d76b2b31c7c@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] RFC: 2.5 todo list. List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Soetens Cc: Xenomai core Peter Soetens wrote: > On Tue, Sep 29, 2009 at 19:31, Gilles Chanteperdrix > wrote: >> Hi guys, >> >> full of energy after this tremendous first XUM, I would like to start a >> discussion about what people would like to see in the 2.5 branch. > > So if we answer positively, we'll delay the release ? I'd rather get > 2.5 out, and develop any new stuff on 2.6. I would also expect that > this list (or part of ) goes to xenomai-help too. The facts are: - our release cycle is long; - we want to keep the ABI stable for each branch. So, anything that we want "soon" and that breaks the ABI should be done in the 2.5 branch, otherwise will have to wait 2.6. > >> Here is a first list, please feel free to criticize it: >> - signals in primary domain (something that we almost forgot) > > I refrain from using signals in my apps. They only cause disaster when > using 3rd party libraries. Only Ctrl-C (quit) and debugger signals are > used, and a switch from primary to secondary is perfectly acceptable > in these two cases. Yes, signals is a bit of a misnomer, what we actually want is for the kernel to be able to cause the execution of an asynchronous callback in user-space. For the native skin, it would be for the implementation of some hooks. For the posix skin, it would be for the implementation of signasl. The implementation of posix timers is based on signals (except for SIGEV_THREAD, but who uses SIGEV_THREAD in an rt app...), having them cause a switch to secondary mode make them unusable for practical purposes. So, with the current version of Xenomai posix skin, you have to implement your own timer method, having for instance a thread which nanosleep()s until the next timer expiry and then executes the callback. > >> - xnsynch_acquire using atomic_cmpxchg unconditionally (no #ifdefs) > > This is too core for me. > >> - statistics of all mapped named heaps in /proc/xenomai/heap > > Don't use heaps since we do all in user space (and I had the > impression that heap was for kernel<->user.) > >> - unwapped access to user-space posix skin methods > > I wouldn't know why I need this. Do you we link with libpthread > instead of libpthread-rt ? Well the wrap thing is a bit cumbersome. And having the calls be named with exactly the posix name is useful only if you intend to compile exactly the same code for xenomai and other posix systems. Otherwise, you could decide to use a little prefix or suffix to each posix skin service, and avoid the wrapping clumsyness. > >> - fast semaphores in user-space > > I donn't know why I wouldn't need this. > >> - syscall-less select ? > > Since a syscall is not per-se bad (?) I also don't see what to win here. syscall are expensive (which is why we do syscall-less mutexes for instance). The idea would be to put the bitfield with the ready file descriptors in a shared heap, to avoid going for the syscall if fds are already ready when entering select(). The scenario where we would gain is on a loaded system, which is exactly when we want to avoid useless syscalls. > >> Actually, there are already a lot of things. >> So, what do you think? > > I'm uttermost concerned with stability and to a lesser extent > performance. I regard every feature change as changing those two > criteria for the worse (unless its a feature that fixes a bug). Well... I disagree. Even when fixing bugs we can introduce other bugs. What matters if you aim for stability and performance is improving the tests, not avoiding modifications. -- Gilles