lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c8b4dbe10709141407p757d0909s5a4d49a7eb44d929@mail.gmail.com>
Date:	Fri, 14 Sep 2007 22:07:36 +0100
From:	"Aidan Thornton" <makosoft@...glemail.com>
To:	"Michael Krufky" <mkrufky@...uxtv.org>
Cc:	"Mauro Carvalho Chehab" <mchehab@...radead.org>,
	"Manu Abraham" <abraham.manu@...il.com>,
	"video4linux-list@...hat.com" <video4linux-list@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-dvb@...uxtv.org" <linux-dvb@...uxtv.org>
Subject: Re: [linux-dvb] [PATCH] Userspace tuner

Hi,

On 9/14/07, Michael Krufky <mkrufky@...uxtv.org> wrote:
> On 9/14/07, Mauro Carvalho Chehab <mchehab@...radead.org> wrote:
> > > > - The hybrid tuner support, that where your requirement, when all those
> > > > discussions started, were already added to the subsystem. So now, an
> > > > hybrid tuner can be accessed by both DVB and V4L devices;
> > > >
> > >
> > > It's far more complex as the thing which is implemented there.
> > > The only thing that has been implemented is that one moduleformat
> > > can be loaded by the v4l and by the dvb framework nothing else at the
> > > moment. I told you at the kernel summit about that and I think you
> > > knew about that before.
> > >
> > > Just to quote some text:
> > > "Right now, a separate instance of the driver is used for analog /
> > > digital tuning.  In order to use a single instance, we will have to
> > > store a pointer to the dvb_frontend structure on the bridge level, but
> > > there are various other prerequisites that must be dealt with before we
> > > get to that point.
> > >
> > > We _will_ get there though, eventually."
> >
> > Maybe it is still not perfect. Feel free to improve it. Several people
> > from the community, including me, already offered you help to add your
> > driver, reworking on the 5% of the stuff that aren't compatible with the
> > V4L/DVB core API design.
>
> For clarification, Markus is quoting me, above.
>
> The idea is to eventually store a pointer to the dvb_frontend
> structure on the bridge level to be used as a single entry point
> between the analog and digital subsystems.  However, we are not yet
> ready for this, as the refactoring process has a lot more to be done
> beforehand.

I think this will require a rethink of either how the em2880-dvb
driver works or how frontend drivers work. The current API expects
users to initialise their frontend and then bind a tuner to it.
em2880-dvb is a sort of subdriver that attaches to the main driver,
and doesn't have any control over when or how it initialises its
tuner, so it can't delay tuner initialisation until the frontend has
been initialised. (I don't think it's the only hybrid driver that
works this way either). Of course, I could be missing something.

> There is no reason why the Xceive driver cannot be merged into the
> current development tree using the hybrid tuner framework as it stands
> today.

I'm not convinced this is entirely true. In order to avoid unnecessary
reinitialisation of the device, the driver needs to know whether the
device is in analog or digital mode, and I can't see a way of doing it
with the current API. (I think existing drivers, such as the xc2028
driver in one branch, use the older analog API and make the digital
driver a wrapper around it.) Again, I may be missing something.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ