* [Xenomai] Road to 3.0
@ 2014-02-25 17:54 Philippe Gerum
2014-02-25 18:11 ` Gilles Chanteperdrix
0 siblings, 1 reply; 9+ messages in thread
From: Philippe Gerum @ 2014-02-25 17:54 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Kiszka, Jan, Xenomai
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.
* 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.
- /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 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.
- 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.
--
Philippe.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xenomai] Road to 3.0
2014-02-25 17:54 [Xenomai] Road to 3.0 Philippe Gerum
@ 2014-02-25 18:11 ` Gilles Chanteperdrix
2014-02-26 9:40 ` Philippe Gerum
0 siblings, 1 reply; 9+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-25 18:11 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Kiszka, Jan, Xenomai
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xenomai] Road to 3.0
2014-02-25 18:11 ` Gilles Chanteperdrix
@ 2014-02-26 9:40 ` Philippe Gerum
2014-02-27 12:12 ` Gilles Chanteperdrix
0 siblings, 1 reply; 9+ messages in thread
From: Philippe Gerum @ 2014-02-26 9:40 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Kiszka, Jan, Xenomai
On 02/25/2014 07:11 PM, Gilles Chanteperdrix wrote:
> 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.
>
There will be significant differences, and I'd rather split the entire
documentation, compared to crippling this material with version-specific
notes and footers.
--
Philippe.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xenomai] Road to 3.0
2014-02-26 9:40 ` Philippe Gerum
@ 2014-02-27 12:12 ` Gilles Chanteperdrix
2014-02-27 13:37 ` Philippe Gerum
0 siblings, 1 reply; 9+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-27 12:12 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Kiszka, Jan, Xenomai
On 02/26/2014 10:40 AM, Philippe Gerum wrote:
> On 02/25/2014 07:11 PM, Gilles Chanteperdrix wrote:
>
>> 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.
>>
>
> There will be significant differences, and I'd rather split the entire
> documentation, compared to crippling this material with version-specific
> notes and footers.
What I meant is that it is already split. The direct links to
README.INSTALL, TROUBLESHOOTING and manual pages point to the 2.6 directory.
--
Gilles.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xenomai] Road to 3.0
2014-02-27 12:12 ` Gilles Chanteperdrix
@ 2014-02-27 13:37 ` Philippe Gerum
2014-02-27 13:40 ` Gilles Chanteperdrix
0 siblings, 1 reply; 9+ messages in thread
From: Philippe Gerum @ 2014-02-27 13:37 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Kiszka, Jan, Xenomai
On 02/27/2014 01:12 PM, Gilles Chanteperdrix wrote:
> On 02/26/2014 10:40 AM, Philippe Gerum wrote:
>> On 02/25/2014 07:11 PM, Gilles Chanteperdrix wrote:
>>
>>> 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.
>>>
>>
>> There will be significant differences, and I'd rather split the entire
>> documentation, compared to crippling this material with version-specific
>> notes and footers.
>
> What I meant is that it is already split. The direct links to
> README.INSTALL, TROUBLESHOOTING and manual pages point to the 2.6
> directory.
>
With that layout, we can't explicitly access to a particular
version-specific documentation bundle from the heading menu. So when we
will move current to 3.x, most of the user base which runs 2.6 will
suddenly refer implicitly to 3.x documentation, which may be confusing.
This is why I suggest that we explicitly split the documentation
bundles. Besides, more documentation material for 3.x may exist in the
future which may not have any counterpart in 2.x.
--
Philippe.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xenomai] Road to 3.0
2014-02-27 13:37 ` Philippe Gerum
@ 2014-02-27 13:40 ` Gilles Chanteperdrix
2014-02-27 13:54 ` Philippe Gerum
0 siblings, 1 reply; 9+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-27 13:40 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Kiszka, Jan, Xenomai
On 02/27/2014 02:37 PM, Philippe Gerum wrote:
> On 02/27/2014 01:12 PM, Gilles Chanteperdrix wrote:
>> On 02/26/2014 10:40 AM, Philippe Gerum wrote:
>>> On 02/25/2014 07:11 PM, Gilles Chanteperdrix wrote:
>>>
>>>> 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.
>>>>
>>>
>>> There will be significant differences, and I'd rather split the entire
>>> documentation, compared to crippling this material with version-specific
>>> notes and footers.
>>
>> What I meant is that it is already split. The direct links to
>> README.INSTALL, TROUBLESHOOTING and manual pages point to the 2.6
>> directory.
>>
>
> With that layout, we can't explicitly access to a particular
> version-specific documentation bundle from the heading menu.
The problem is the nenu, not the layout of the documentation. As I said,
on the server disk, the documentation is already split.
You can try:
http://www.xenomai.org/documentation/xenomai-2.5/README.INSTALL
http://www.xenomai.org/documentation/xenomai-2.4/README.INSTALL
And you will find previsous versions installation instructions.
--
Gilles.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xenomai] Road to 3.0
2014-02-27 13:40 ` Gilles Chanteperdrix
@ 2014-02-27 13:54 ` Philippe Gerum
2014-02-27 14:04 ` Gilles Chanteperdrix
0 siblings, 1 reply; 9+ messages in thread
From: Philippe Gerum @ 2014-02-27 13:54 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Kiszka, Jan, Xenomai
On 02/27/2014 02:40 PM, Gilles Chanteperdrix wrote:
> On 02/27/2014 02:37 PM, Philippe Gerum wrote:
>> On 02/27/2014 01:12 PM, Gilles Chanteperdrix wrote:
>>> On 02/26/2014 10:40 AM, Philippe Gerum wrote:
>>>> On 02/25/2014 07:11 PM, Gilles Chanteperdrix wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> There will be significant differences, and I'd rather split the entire
>>>> documentation, compared to crippling this material with
>>>> version-specific
>>>> notes and footers.
>>>
>>> What I meant is that it is already split. The direct links to
>>> README.INSTALL, TROUBLESHOOTING and manual pages point to the 2.6
>>> directory.
>>>
>>
>> With that layout, we can't explicitly access to a particular
>> version-specific documentation bundle from the heading menu.
>
> The problem is the nenu, not the layout of the documentation. As I said,
> on the server disk, the documentation is already split.
>
> You can try:
> http://www.xenomai.org/documentation/xenomai-2.5/README.INSTALL
> http://www.xenomai.org/documentation/xenomai-2.4/README.INSTALL
>
> And you will find previsous versions installation instructions.
>
Thanks, I'm aware of this. My point is: would you ask anyone who wants
to find information about the RTDM API over 2.6 to know about a URL? Or
shall we kill that menu in its current form, and provide something less
confusing, which can be found on the main page?
Now, we might point people at:
http://xenomai.org/index.php/Included_documentation_summary
Unfortunately, 3.x has a migration guide which 2.x does not have, 3.x
does not have a "native" API but an "alchemy" API, and 3.x will likely
have distinct/additional testing tools from 2.x. So this won't fly.
http://xenomai.org/index.php/<version>/Included_documentation_summary
would make more sense in this case.
But again, regardless of the layout of the information on disk which no
user cares a dime about, this is first and foremost a problem with the
layout of the information on the website's main page.
--
Philippe.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xenomai] Road to 3.0
2014-02-27 13:54 ` Philippe Gerum
@ 2014-02-27 14:04 ` Gilles Chanteperdrix
2014-02-27 14:29 ` Philippe Gerum
0 siblings, 1 reply; 9+ messages in thread
From: Gilles Chanteperdrix @ 2014-02-27 14:04 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Kiszka, Jan, Xenomai
On 02/27/2014 02:54 PM, Philippe Gerum wrote:
> On 02/27/2014 02:40 PM, Gilles Chanteperdrix wrote:
>> On 02/27/2014 02:37 PM, Philippe Gerum wrote:
>>> On 02/27/2014 01:12 PM, Gilles Chanteperdrix wrote:
>>>> On 02/26/2014 10:40 AM, Philippe Gerum wrote:
>>>>> On 02/25/2014 07:11 PM, Gilles Chanteperdrix wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> There will be significant differences, and I'd rather split the entire
>>>>> documentation, compared to crippling this material with
>>>>> version-specific
>>>>> notes and footers.
>>>>
>>>> What I meant is that it is already split. The direct links to
>>>> README.INSTALL, TROUBLESHOOTING and manual pages point to the 2.6
>>>> directory.
>>>>
>>>
>>> With that layout, we can't explicitly access to a particular
>>> version-specific documentation bundle from the heading menu.
>>
>> The problem is the nenu, not the layout of the documentation. As I said,
>> on the server disk, the documentation is already split.
>>
>> You can try:
>> http://www.xenomai.org/documentation/xenomai-2.5/README.INSTALL
>> http://www.xenomai.org/documentation/xenomai-2.4/README.INSTALL
>>
>> And you will find previsous versions installation instructions.
>>
>
> Thanks, I'm aware of this. My point is: would you ask anyone who wants
> to find information about the RTDM API over 2.6 to know about a URL? Or
> shall we kill that menu in its current form, and provide something less
> confusing, which can be found on the main page?
>
> Now, we might point people at:
> http://xenomai.org/index.php/Included_documentation_summary
>
> Unfortunately, 3.x has a migration guide which 2.x does not have, 3.x
> does not have a "native" API but an "alchemy" API, and 3.x will likely
> have distinct/additional testing tools from 2.x. So this won't fly.
>
> http://xenomai.org/index.php/<version>/Included_documentation_summary
> would make more sense in this case.
>
> But again, regardless of the layout of the information on disk which no
> user cares a dime about, this is first and foremost a problem with the
> layout of the information on the website's main page.
>
What I meant is that it is a much easier task than having to change the
way the documentation is kept up-to-date on the server. Of course users
do not care, they are not the ones who maintain the server-side scripts.
--
Gilles.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Xenomai] Road to 3.0
2014-02-27 14:04 ` Gilles Chanteperdrix
@ 2014-02-27 14:29 ` Philippe Gerum
0 siblings, 0 replies; 9+ messages in thread
From: Philippe Gerum @ 2014-02-27 14:29 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Kiszka, Jan, Xenomai
On 02/27/2014 03:04 PM, Gilles Chanteperdrix wrote:
> On 02/27/2014 02:54 PM, Philippe Gerum wrote:
>> On 02/27/2014 02:40 PM, Gilles Chanteperdrix wrote:
>>> On 02/27/2014 02:37 PM, Philippe Gerum wrote:
>>>> On 02/27/2014 01:12 PM, Gilles Chanteperdrix wrote:
>>>>> On 02/26/2014 10:40 AM, Philippe Gerum wrote:
>>>>>> On 02/25/2014 07:11 PM, Gilles Chanteperdrix wrote:
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> There will be significant differences, and I'd rather split the
>>>>>> entire
>>>>>> documentation, compared to crippling this material with
>>>>>> version-specific
>>>>>> notes and footers.
>>>>>
>>>>> What I meant is that it is already split. The direct links to
>>>>> README.INSTALL, TROUBLESHOOTING and manual pages point to the 2.6
>>>>> directory.
>>>>>
>>>>
>>>> With that layout, we can't explicitly access to a particular
>>>> version-specific documentation bundle from the heading menu.
>>>
>>> The problem is the nenu, not the layout of the documentation. As I said,
>>> on the server disk, the documentation is already split.
>>>
>>> You can try:
>>> http://www.xenomai.org/documentation/xenomai-2.5/README.INSTALL
>>> http://www.xenomai.org/documentation/xenomai-2.4/README.INSTALL
>>>
>>> And you will find previsous versions installation instructions.
>>>
>>
>> Thanks, I'm aware of this. My point is: would you ask anyone who wants
>> to find information about the RTDM API over 2.6 to know about a URL? Or
>> shall we kill that menu in its current form, and provide something less
>> confusing, which can be found on the main page?
>>
>> Now, we might point people at:
>> http://xenomai.org/index.php/Included_documentation_summary
>>
>> Unfortunately, 3.x has a migration guide which 2.x does not have, 3.x
>> does not have a "native" API but an "alchemy" API, and 3.x will likely
>> have distinct/additional testing tools from 2.x. So this won't fly.
>>
>> http://xenomai.org/index.php/<version>/Included_documentation_summary
>> would make more sense in this case.
>>
>> But again, regardless of the layout of the information on disk which no
>> user cares a dime about, this is first and foremost a problem with the
>> layout of the information on the website's main page.
>>
> What I meant is that it is a much easier task than having to change the
> way the documentation is kept up-to-date on the server. Of course users
> do not care, they are not the ones who maintain the server-side scripts.
>
Sure, the scripts are maintained to provide them with information they
can find. I take for granted that at some point, we will have to think
about all this.
--
Philippe.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-02-27 14:29 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-25 17:54 [Xenomai] Road to 3.0 Philippe Gerum
2014-02-25 18:11 ` Gilles Chanteperdrix
2014-02-26 9:40 ` Philippe Gerum
2014-02-27 12:12 ` Gilles Chanteperdrix
2014-02-27 13:37 ` Philippe Gerum
2014-02-27 13:40 ` Gilles Chanteperdrix
2014-02-27 13:54 ` Philippe Gerum
2014-02-27 14:04 ` Gilles Chanteperdrix
2014-02-27 14:29 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.