On Tue, 2008-05-27 at 20:46 -0400, Devin Heitmueller wrote:
quoted text
> Hello Andy,
> 
> On Tue, May 27, 2008 at 7:48 PM, Andy Walls <awalls@radix.net> wrote:
> > MythTV's mythbackend can open both sides of the card at the same time
> > and the cx18 driver supports it.  On my HVR-1600, MythTV may have the
> > digital side of the card open pulling EPG data off of the ATSC
> > broadcasts, when I open up the MythTV frontend and start watching live
> > TV on the analog side of the card.  MythTV also supports
> > Picture-in-Picture using both the analog and digital parts of the
> > HVR-1600.
> 
> In this case, what you see as a 'feature' in MythTV is actually a
> problem in our case.  While the HVR-1600 can support this scenario,
> the HVR-950 can only use one or the other (the em28xx chip uses GPIOs
> to enable the demodulator and presumably you should never have both
> demodulators enabled at the same time).  Because of this we need a
> lock.  If MythTV only opened one device or the other at a time, we
> could put the lock on the open() call, but since MythTV opens both
> simultaneously even though it may only be using one, we would need a
> much more granular lock.

I don't think a lock would be good for MythTV or any other app that
open()s multiple nodes at once.  How can an app know that it's
dead-locking or barring itself via the kernel driver?

Maybe return an EBUSY or E-something else for these cases when Myth
tries to open() the second device node, when there's an underlying
factor that requires things to be mutually exclusive.  Allowing things
like read() to allow hardware mode switching between analog and digital
seems like it could result in really weird behaviors at the application.

I'll cite a precedent:
ivtv returns EBUSY on open() when there's a conflict with it's various
analog devices nodes that depend on the same underlying hardware: MPG,
YUV, FM Radio, etc.

I note the man page for open() doesn't list EBUSY as a valid errno.
However, the V4L2 API Spec does list EBUSY as a valid errno for V4L2
open().


quoted text
> Certainly I'm not blaming MythTV for this behavior, but it will make
> the locking much more complicated in some hybrid devices.

I like to blame MythTV for a lot of things. ;)

But in this case I can't.  The driver probably shouldn't hold a lock and
suspend an open() indefinitely (IMO).  It should say the device is BUSY
as that is the truth: an underlying hardware device or resource is busy.


Regards,
Andy

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/