[ag-automation] neuer Mitleser

[Thomas Gleixner]

Hi Jan,

> As I said, given an open mind on both sides to see the other one's
> issues as well, we may find a common ground for both "domains". I heard
> you are also planning to promote a focused and lean API to RT-driver
> developers? Looks like we are heading for similar goals here.

Yeah, I'm busy cleaning up the existing framework for - non message
based - industrial I/O drivers with an eye on RT and the usability as a
base for generic user space device drivers.

> > ...
> > I'm really curious how the Van Jacobson idea will change the situation
> > and I would appreciate if somebody with your experience would actively
> > participate on that development. It's a simple fact, that those who do
> > the work have large influence on the design and the outcome.
> 
> I know very well, and I'm trying hard to redirect some brain cycles on
> this (reminds me of Esben's reply...).

/me sends Jan some spare cycles :)

> I'm sorry that you have to enlighten me here. While I was correctly
> remembering that the default type behaviour of mutexes is undefined, I
> failed to find a statement in the spec regarding the default protocol.
> If there is one that doesn't match the current version, this has to be
> fixed, for sure.

As far as I can see, the default is a normal mutex without any special
attributes and protocols. At least are all conformance tests based on
this assumption. 

Running such tests is helpful also for documentation purposes, so we can
easily setup a "supported feature" matrix. This has been discussed at
the workshop already and Robert volunteered to take care of this, IIRC.

> > The basic design is in a way, which allows to address the problem simply
> > by preallocating the data structures in a non shrinkable private futex
> > slab.
> 
> That's a good sign - though I would personally prefer a way to trigger
> this allocation during init, not at some harder-to-predict point during
> runtime. What about process-scope futexes to overcome global
> hash-bucket-lock dependencies at least for the non-pshared case? Already
> on the roadmap?

Yeah. I already thought about that and it's on my "what to do in case of
boredom" list :)

> >> 			Single Domain		Separate Domains
> >>
> >> memory-sucking apps	services are delayed	(separate pools to
> >> or NRT-drivers		or fail which depend 	confine impact)
> >> 			on availability
> > 
> > See above.
> 
> Yep, getting closer, but still not totally decoupling RT from NRT
> threads. But I assume that this will be the next-but-one step, and
> concepts for remaining subsystems are under development as well.

Right. These are steps in the pipeline once we get large enough chunks
from the patch into mainline. Our current focus is to clean up and
sanitize large and crucial parts for mainline inclusion and get some
still hot discussed topics out of the way.

> But one point is, e.g., that many drivers still uses local_irq_save() &
> friends for critical path protection and that those calls even happen in
> IRQ context (due to commonly used functions). Those code paths do need
> review regarding potential lock-ups or high latencies (due to bugs or
> sluggish hardware). Another one is incorrect usage of locking
> primitives, e.g. things that touches the preemption lock or clumsy
> nesting with central locks.
> 
> I assume that the Preempt-rt community already did quite an intensive
> review of in-kernel drivers (if not all yet, a list of those being save
> would be good, BTW). It would be really great for the overall driver
> quality if such a strong and continued review on both in-kernel and
> relevant third-party drivers will be provided around the Preempt-rt
> project, no question.

Well, recently we started to do automated testing on board farms. The
tests run with a lot of debugging options enabled. Aside the problems we
solved during the development and the new testing facilites (which need
more hardware and should be done on more locations of course) - the
related bugfixes are in the range of several hundreds by now - actually
mainline developers start to use preempt-rt to stress test their drivers
and subsystems.

> > If your forklift relies on a pure software solution, please let me know
> > where it drives around in the wild, so I can avoid to meet it.
> 
> [Then don't visit the manufacturer. ;)]

Hehe

> Of course, we also have "hardware"-based safety features on board,
> including remote emergency-off. But I guess I do not have to explain
> that the amount of software involved even in such elementary functions
> is constantly increasing. Specifically, not all safety properties of
> service robots can by realised on small dedicated controllers anymore.

I know, but we really have to keep an eye on the balance of what's
really necessary and what's a nice to have but costly feature.

	tglx