Gerd Knorr wrote:
v4l2 patch has the priority stuff in, structs + ioctls in
videodev2.h, some helper functions in v4l2-common.c to keep patches
for the drivers small. Only three levels. Completely untested so
far. Comments?
Looks fine to me. Only, since you're using a separate semaphore for
priority updates - which drivers will probably not apply in addition to
the hardware access semaphore around execution of SET ioctls - it might
be better to modify v4l2_prio_change() so that the new prio is set
before the old one is released. Else a low-prio SET ioctl might get
through in the middle (e.g. between a change from interactive to record
level.)
David Balazic wrote:
The problem of using limited resources in a multi-user/tasking
environment is not exactly new. Before you reinvent the wheel, you
could look up some existing solutions.
Actually the proposed event reporting mechanism is derived from
poll() and the priority handling is in effect simply a semaphore.
So I think I've done my share of reusing :)
IMHO the hard part is not finding a solution, but figuring out the
problem, i.e. what will future video/vbi/audio input/output apps
require? I'll readily admit that my proposal is mainly based on
requirements which are derived from my own applications and
experiences. If you have anything to add, then please speak up.
Also note that my proposal isn't about adding resource and/or rights
management into the driver (*), instead it's about leaking just enough
information to allow capture processes themselves to limit or manage
side-effects of parameter changes in shared resources. In regard to
actual capturing (including overlay and output etc.) it's still good
old "first come/first serve". Multi-user isn't considered at all.
(* With the exception of priority checks which is the only way to
avoid a race. But still priorities are used in a cooperative way
since they can be defined freely.)
bye,
-tom
