Re: [Xenomai-help] Generel problem with realtime-tops(like adeos) over linux-kernel

[Jan Kiszka <jan.kiszka@domain.hid>]

Schlägl Manfred jun. wrote:
> Hi!
> 
> I think we've discovered a generell logical problem with realtime-tops
> like adeos over the linux-kernel.
> 
> The basic-assumption of such an system is: Linux is not a
> realtime-system, so it is not able to provide realtime to it's services,
> so no linux-service is able to use realtime-capabilities, so no
> linux-service has realtime-requirements.
>>From this it follows that we are able use a top like adeos (send
> interrupts later, always interrupt the linux-kernel).
> 
> But... Linux is able to provide hard-realtime while interrupts are
> locked. And many services(driver) use this.
> 
> abstract example:
> {{{
> spin_lock_irqsave
> if(hardware_data_valid())
> 	process_hardware_data()
> spin_lock_irqrestore
> }}}
> works fine without adeos, but with adeos there may be a relative long
> interruption between validation and processing. The hardware may overrun
> and process_hardware_data is called without valid data...

For those rare cases (compared to the mass of locks that don't need
this), you can still convert the lock into a hard one again. See e.g.
how IRQ controllers (which are shared between Linux and other Adeos
domains) are handled by the I-pipe patch, watching out for
ipipe_spinlock_t specifically.

> 
> In our case we have this problem while the rx-interrupt of our
> ethernet-driver. The dma is running permanently and generates an overrun
> between the error-checking(which would catch the overrun) part and the
> data-processing part of the handler.
> 
> I think it is possible that there could be many such (latent) problems
> in linux-kernel. For example USB which itself has realtime-requirements,
> or eventually mtd (lost data as cause of wrong flash-write/erase
> timings), ...
> 
> So ... what do you think about that.

Most hardware does not have such hard requirements. IIRC, USB does not.

Also note that long hard IRQ-off phases are highly disliked in mainline
Linux as well, and kernel developers will happily accept sound patches
avoiding such phases. This also simplifies the path toward PREEMPT_RT
(which effectively does the same to these locks that Adeos does).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux