On Fri, 2010-04-30 at 08:43 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Mon, 2010-04-26 at 19:09 +0200, Gilles Chanteperdrix wrote: 
> >> Jan Kiszka wrote:
> >>> Jan Kiszka wrote:
> >>>> The following changes since commit 
> >>>> 113ea4d56e8b215cb56ae7673013163ea5a5987d:
> >>>>   Gilles Chanteperdrix (1):
> >>>>         switchtest: increase stack sizes
> >>>>
> >>>> are available in the git repository at:
> >>>>
> >>>>   git://git.xenomai.org/xenomai-jki.git queues/proc
> >>>>
> >>>> This series fixes some of the potential (but when they happen fatal)
> >>>> overflows in our procfs outputs. Specifically, it fixes all issues in
> >>>> RTDM (one of them hit us in the field) and the recently reported
> >>>> overflow in /proc/xenomai/heap. Moreover, Wolfgang started the lengthy
> >>>> conversion of the registry by introducing a new seq_file-based interface
> >>>> and already moving the native skin over.
> >>>>
> >>>> The future belongs to seq_file, so some of the patches are strictly
> >>>> spoken not yet required. But we better start this effort before the last
> >>>> legacy interface user was converted and the old interface is suddenly
> >>>> dropped from the kernel. This may not be that far away. A patch of mine
> >>>> to improve error reporting of the old interface was rejected with
> >>>> "->read_proc is going to be removed, so there is no point."
> >>> Did you already have a chance to look into this series?
> >> Not yet, that is a big series. With a high potential for kernel crashes,
> >> memory leaks and other things like that. I am trying to find a way to
> >> test it. Maybe we can try and run it with kmemcheck?
> >>
> > 
> > Looking at this series, I eventually made my mind about the kind of
> > support I'd wish in this area. It boils down to:
> > 
> > - getting rid of the PAGE_SIZE limitation on read as this series does,
> > - reducing the impact on latency of large outputs,
> > - hiding discrepancies between linux kernel
> > releases, regarding the proper way to export kernel object states
> > to userland (like the planned deprecation of read procs).
> > - providing a common encapsulation to do that, which brings all the
> > previous properties in a normalized way, and helps removing direct
> > dependencies of other core code on PROC_FS
> > - rebasing the registry support on top of this feature, so that skins
> > are automatically feature-enabled when going through the registry to
> > export stuff to userland (as they should).
> > 
> > To this end, I came up with the so-called "virtual file" (aka vfile)
> > support for the nucleus, and have toyed with those ideas here: 
> > git://git.xenomai.org/xenomai-rpm.git       queue/vfile
> > 
> > This is still early work in progress, not all the codebase was converted
> > to use the vfiles (registry and native API were), and I tested the
> > result only in a very limited manner; so this is not for inclusion into
> > 2.5.x given the amount of code that touches anyway. But I will likely
> > submit this for inclusion at some point into any upcoming 2.6.x, if
> > vfiles turn out to fit the job.
> > 
> Looks good on first sight to simplify all our revision-based list walks
> (and those that should better work like that). To make it a universal
> abstraction for /proc/xenomai (or what ever it will be in the future), I
> think just a bit more flexibility is required.
> Specifically, we a way to modify the locking and data acquisition
> strategy. We have nodes that do not require any locking at all but still
> want to use the seq_file pattern. And we have some nodes that use
> different locks, including Linux semaphores/mutexes. I think if you
> allow to specify the lock to be used and its type (xnlock or Linux mutex
> - BTW, a good chance to wrap away semaphores for legacy kernels), all
> required use cases should be covered:
>  - xnlock -> revision-based ahead-of-print data acquisition
>  - Linux mutex -> simply hold the lock while printing
>  - NULL -> provide lockless seq_file printing

That makes sense. To do this sanely, I will have to raise the
abstraction level a bit more to specialize the vfile base, for deriving
both a snapshot-driven vfile (the current one), and a regular one (the
linux kind of seqfile), for which a locking resource may be specified. I
will extend this code accordingly.

> Jan


Xenomai-core mailing list

Reply via email to