[ag-automation] neuer Mitleser

[Jan Kiszka]

Hi Thomas,

[sorry for the late reply - busy...]

Thomas Gleixner wrote:
> On Mon, 2006-04-10 at 10:29 +0200, Jan Kiszka wrote:
> 
>> From the user perspective, RTDM adds a small amount of new kernel
>> services (like all Xenomai skins) which can both be used by non-POSIX
>> skins (native, VxWorks, etc., that's the rt_dev_ interface) or be
>> mapped on the original POSIX service as done inside the POSIX stub
>> library. [This is how it works under Xenomai and RTAI, but on
>> Preempt-RT we would of course use the existing file and socket
>> infrastructure.]
> 
> Could you please explain the basics of RTDM and how an integration into
> mainline (w or w/o rt-preempt) would look like ?

From a higher point of view, the basic idea of RTDM is threefold:

1. Keeping the interface a hard-RT driver has to provide limited and
   targeted. This aims at reducing the amount of code one has to
   maintain with respect to both logical correctness and determinism.

   More in details, RTDM focuses on basic POSIX I/O services (read /
   write / ioctl) and the socket interface (recvmsg / sendmsg &
   friends). Invocations are passed to driver handlers separated
   according to the caller's scheduling policy (RT or non-RT). An RTDM
   driver can register dedicated handlers for each context, providing,
   e.g., resource allocation policies depending on the criticality of
   the caller or rejecting wrong usages.

2. Providing a driver development interface for the time-critical part
   that is independent of the underlying RTOS (and its potential
   modifications over the time). This concept was (re-)born in the days
   when Preempt-rt was far from being in sight. So the current
   realisation may require a careful rebalancing when including
   Preempt-rt support.

   I think the current API already covers a fair range of RT-scenarios,
   but there are a few further points remaining on the roadmap, e.g.
   wrapping of timer services or generalised packet pools for real-time
   networking stacks.

3. Defining sets of generic services that device driver classes shall
   offer. These specifications are called RTDM profiles. The idea is to
   remain compatible to existing drivers where feasible and reasonable.
   But specifically in the automation domain, generic interfaces are not
   even available. So, some work remains to be done for everyone.


Item 1 should be straightforward to realise over Preempt-rt, as there
are already deterministic system entries for the RTDM service set, only
adoption of the handler signatures are required. Also item 2 will mostly
just demand name mapping (for mutexes e.g.) or minor wrapping.

But regarding mainline integration of this layer: well, if this is going
to be the ultimate criteria, RTDM may fail. Without preempt-rt in the
kernel, it doesn't make sense to think about this at all. But even with
preempt-rt, I'm a bit sceptical that the current kernel community will
like the idea of including a layer which aims at keeping code compilable
also against something outside their yard.

While I'm perfectly fine with letting code flow together with the kernel
development to achieve best average efficiency, I'm not convinced to do
the same with stuff used for critical applications. Therefore RTDM.
That's my view, but maybe I (and other sharing my view) will be proven
wrong in the next years. :)


But first keep the integration out of the focus. I'm sure we can more
easily agree on the specification part, i.e. the device driver profiles.
CAN is such an example where we are on a good way to achieve a
compatible programming model, independent of the underlying
implementation details.

> 
>> Not yet, but it seems to be the announcement text. Typically, I prefer a
>> code review over documentation, and the aspects I'm referring to (risk
>> of -ENOMEM on mutex lock, hash chain lock dependencies on futex look-up,
>> tasklist_lock dependencies) were not mentioned in the announcements yet.
> 
> This really depends on what you want to achieve. The PI-Futex
> implementation is focussed on the optimization of the non contended
> case. Enforcing a syscall per lock operation is definitely something you
> want to avoid. The original Bull/Intel/MVista patch did exactly this and
> its rather simple to figure out whats the overhead.

As you said, this depends on your scenario. I can very well imagine
large, complex applications (telco...) where your definitely smart
optimisations help a lot. But I can also imagine scenarios (tight
control loops e.g.) where you better spend a few percentage efficiency
for guarantees. So, both ways should be selectable so that only those
applications pay which have to. Note that this does not necessarily mean
to enter the kernel in the non-contended case, I could imagine
optimisation potential for Xenomai as well here.

> 
> If you trap into the -ENOMEM situation in the locking code, then your
> system has reached its limits anyway.

That's easy to claim, but I don't see why a well configured Linux box
shouldn't keep their time critical jobs alive and working even under
memory pressure. Bugs are everywhere, e.g. memory leaks in
not-that-well-reviewed non-RT applications. Ok, I recently noticed that
the out-of-memory manager of 2.6 doesn't make this goal easier, but it
still remains feasible and worth to achieve.

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : https://lists.osadl.org/pipermail/ag-automation/attachments/20060411/e68ac26a/signature.pgp