Re: Should we mark RTDS as supported feature from experimental feature?

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3256 bytes --]

On Mon, 2016-04-25 at 21:44 -0400, Meng Xu wrote:
> Hi Dario and all,
> 
Hi,

> When RTDS scheduler is initialized, it will print out that the
> scheduler is an experimental feature with the following lines:
> 
>     printk("Initializing RTDS scheduler\n"
> 
>            "WARNING: This is experimental software in development.\n"
> 
>            "Use at your own risk.\n");
> 
> On RTDS' wiki [1], it says the RTDS scheduler is experimental
> feature.
> 
Yes.

> However, inside MAINTAINERS file, the status of RTDS scheduler is
> marked as Supported (refer to commit point 28041371 by Dario Faggioli
> on 2015-06-25).
> 
There's indeed a discrepancy between the way one can read that bit of
MAINTAINERS, and what is generally considered Supported (e.g., subject
to security support, etc).

This is true in general, not only for RTDS (more about this below).

> In my opinion, the RTDS scheduler's functionality is finished and
> tested. So should I send a patch to change the message printed out
> when the scheduler is initialized?
> 
So, yes, the scheduler is now feature complete (with the per-vcpu
parameters) and adheres to a much more sensible and scalable design
(event driven). Yet, these features have been merged very recently,
therefore, when you say "tested", I'm not so sure I agree. In fact, we
do test it on OSSTest, but only in a couple of tests. The combination
of these two things make me think that we should allow for at least
another development cycle, before considering switching.

And speaking of OSSTest, there have benn occasional failures, on ARM,
which I haven't yet found the time to properly analyze. It may be just
something related to the fact that the specific board was very slow,
but I'm not sure yet.

And even in that case, I wonder how we should handle such a
situation... I was thinking of adding a work-conserving mode, what do
you think? You may have something similar in RT-Xen already but, even
if you don't, there are a number of ways for achieving that without
disrupting the real-time guarantees.

What do you think?

> If I understand correctly, the status in MAINTAINERS file should have
> the highest priority and information from other sources should keep
> updated with what the MAINTAINERS file says?
> 
> Please correct me if I'm wrong.
> 
This has been discussed before. Have a look at this thread/messages.

http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg00972.html
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01775.html

And at this:
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01992.html

The feature document template has been put together:
http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg01929.html

And there are feature documents in tree already.

Actually, writing one for RTDS would be a rather interesting and useful
thing to do, IMO! :-)

Regards,
Dario
---
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel