public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Brandon Philips <brandon@ifup.org>
Cc: v4l-dvb-maintainer@linuxtv.org, video4linux-list@redhat.com
Subject: Re: [PATCH 0 of 9] videobuf fixes
Date: Mon, 31 Mar 2008 18:31:36 -0300	[thread overview]
Message-ID: <20080331183136.3596bfb3@gaivota> (raw)
In-Reply-To: <20080331192618.GA21600@plankton.ifup.org>

> > The patch is wrong. 
> 
> The patch fixes the unsafe way vivi is doing multiple opens right now
> and I am uninterested in spending anymore time trying to fix up vivi
> right now.  If you could fix vivi up that would be great.  

If the issue is specific to to vivi, that's ok. I'm just wandering if the
changesets would break a driver for a real device.

Unfortunately, I couldn't test your patch on a real hardware. The hardware I use
here to test PCI boards is currently broken[1].

> > 	2) you can see a program with an userspace app and record the
> > 	stream with another app. Both xawtv and xdtv do this, when you
> > 	ask for record: They call mencoder, asking it to read from
> > 	/dev/video0. This way, you'll have the tv app reading, using
> > 	mmap() or overlay methods, while mencoder is calling read() to
> > 	receive the stream.
> 
> Yes, I know.  But, vivi has no permission control mechanism right now
> for differentiating between streaming file handles and control ones.

What the other drivers do is to implement a small code for this lock. You may
take a look on res_get(), for example, on cx88. 

Btw, we had this lock on past versions of vivi, but this were removed on this
changeset:

changeset:   6275:cba23263534b
user:        bphilips@suse.de <bphilips@suse.de>
date:        Thu Sep 27 20:55:17 2007 -0300
files:       linux/drivers/media/video/vivi.c
description:
V4L: vivi.c remove the "resource" locking

The "resource" locking in vivi isn't needed since
streamon/streamoff/read_stream do mutual exclusion using
q->reading/q->streaming.

Maybe we can just revert this changeset.

> > Yet, vivi should allow multiple open to allow "panel" applications, to
> > be compliant with V4L2 API.
> 
> Yes, but someone needs to add the code to support this in vivi.  And
> until someone does vivi can only support one open at a time without
> crashing.

This is a small regression, but I think it is OK for now.

[1] I tried to fix it during the weekend, without success. The Ethernet
interface is not working fine - most of the time, it doesn't send packets.
Also, with 2 PCI's inside, only one is working fine. If I plug 3 PCI devices,
all devices work badly. I tried to replace the power supply, but the troubles
still continue. I think I'll need to start saving some money to buy a newer
hardware :(

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

  reply	other threads:[~2008-03-31 21:31 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-28 10:18 [PATCH 0 of 9] videobuf fixes Brandon Philips
2008-03-28 10:18 ` [PATCH 1 of 9] soc_camera: Introduce a spinlock for use with videobuf Brandon Philips
2008-03-28 20:53   ` Guennadi Liakhovetski
2008-03-29  3:59     ` Brandon Philips
2008-04-04 13:46       ` [PATCH] soc-camera: use a spinlock for videobuffer queue Guennadi Liakhovetski
2008-04-04 20:17         ` Brandon Philips
2008-03-28 10:18 ` [PATCH 2 of 9] videobuf: Require spinlocks for all videobuf users Brandon Philips
2008-03-28 10:18 ` [PATCH 3 of 9] videobuf: Wakeup queues after changing the state to ERROR Brandon Philips
2008-03-28 10:18 ` [PATCH 4 of 9] videobuf: Simplify videobuf_waiton logic and possibly avoid missed wakeup Brandon Philips
2008-03-28 10:18 ` [PATCH 5 of 9] videobuf-vmalloc.c: Remove buf_release from videobuf_vm_close Brandon Philips
2008-03-28 10:18 ` [PATCH 6 of 9] videobuf-vmalloc.c: Fix hack of postponing mmap on remap failure Brandon Philips
     [not found]   ` <20080405131236.7c083554@gaivota>
     [not found]     ` <20080406080011.GA3596@plankton.ifup.org>
     [not found]       ` <20080407183226.703217fc@gaivota>
     [not found]         ` <20080408152238.GA8438@plankton.public.utexas.edu>
2008-04-08 18:40           ` Mauro Carvalho Chehab
     [not found]             ` <c8b4dbe10804081306xb1e8f91q64d1e6d18d3d2531@mail.gmail.com>
2008-04-08 20:50               ` Mauro Carvalho Chehab
     [not found]                 ` <c8b4dbe10804090626l6b2b10d9p1c22e02dfe2850fe@mail.gmail.com>
2008-04-09 20:42                   ` Mauro Carvalho Chehab
     [not found]             ` <20080408204514.GA6844@plankton.public.utexas.edu>
2008-04-08 21:37               ` Mauro Carvalho Chehab
     [not found]                 ` <20080415021558.GA22068@plankton.ifup.org>
2008-04-15 14:10                   ` Mauro Carvalho Chehab
2008-03-28 10:18 ` [PATCH 7 of 9] vivi: Simplify the vivi driver and avoid deadlocks Brandon Philips
2008-03-28 18:34   ` Mauro Carvalho Chehab
2008-03-29  5:35     ` Brandon Philips
2008-03-31 19:35       ` Mauro Carvalho Chehab
2008-03-28 10:18 ` [PATCH 8 of 9] videobuf: Avoid deadlock with QBUF and bring up to spec for empty queue Brandon Philips
2008-03-28 10:18 ` [PATCH 9 of 9] videobuf-dma-sg.c: Avoid NULL dereference and add comment about backwards compatibility Brandon Philips
2008-03-28 19:09 ` [PATCH 0 of 9] videobuf fixes Mauro Carvalho Chehab
2008-03-29  5:25   ` Brandon Philips
2008-03-29 22:49     ` Vanessa Ezekowitz
2008-03-31 18:35     ` Mauro Carvalho Chehab
2008-03-31 19:26       ` Brandon Philips
2008-03-31 21:31         ` Mauro Carvalho Chehab [this message]
2008-04-01  3:11           ` Brandon Philips
2008-04-01 20:49             ` Mauro Carvalho Chehab
2008-04-02 18:54               ` Brandon Philips
2008-04-02 20:06                 ` Mauro Carvalho Chehab
2008-04-02 18:56               ` Brandon Philips

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080331183136.3596bfb3@gaivota \
    --to=mchehab@infradead.org \
    --cc=brandon@ifup.org \
    --cc=v4l-dvb-maintainer@linuxtv.org \
    --cc=video4linux-list@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox