linux-kernel - V4L2 device node centric - Was: [PATCH v4 6/7] media: videodev2: add a flag for MC-centric devices

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]

Date:   Mon, 28 Aug 2017 10:27:51 -0300
From:   Mauro Carvalho Chehab <mchehab@...pensource.com>
To:     Hans Verkuil <hverkuil@...all.nl>
Cc:     Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Mauro Carvalho Chehab <mchehab@...radead.org>,
        linux-kernel@...r.kernel.org,
        Hans Verkuil <hans.verkuil@...co.com>,
        Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>
Subject: V4L2 device node centric - Was: [PATCH v4 6/7] media: videodev2:
 add a flag for MC-centric  devices

Em Mon, 28 Aug 2017 11:41:58 +0200
Hans Verkuil <hverkuil@...all.nl> escreveu:

> > +        control, and thus can't be used by **v4l2-centric** applications.  
> 
> vdev-centric
> 
> TBD: I still think I prefer V4L2-centric over vdev-centric.

I'm splitting it on a separate thread, to make easier for us to discuss.

For those that aren't tracking the patchset that are documenting those
terms, when MC was added, we got a hole new series of V4L2 devices that
are incompatible with standard V4L2 applications, as they require 
knowledge about the hardware sub-devices. We are referring to such
devices as MC-centric. We need another term to refer to the V4L2 devices
that can be used by a generic application, and are fully controlled via a 
V4L2 device (/dev/video*, /dev/radio*, /dev/swradio*, /dev/vbi*,
/dev/v4l-touch*).

The proposed documentation patch series solves this issue by
adding a glossary (patch 1) that defines what a "V4L2 device node"
as:

    V4L2 device node
	 A device node that it is associated to a V4L2 main driver,
	 as specified at :ref:`v4l2_device_naming`.

And, at the device naming chapter, at the spec (patch 2), it
explicitly lists all V4L2 device node names:

	.. _v4l2_device_naming:

	V4L2 Device Node Naming
	=======================

	... 

	The existing V4L2 device node types are:

	======================== ======================================================
	Default device node name Usage
	======================== ======================================================
	``/dev/videoX``		 Video input/output devices
	``/dev/vbiX``		 Vertical blank data (i.e. closed captions, teletext)
	``/dev/radioX``		 Radio tuners and modulators
	``/dev/swradioX``	 Software Defined Radio tuners and modulators
	``/dev/v4l-touchX``	 Touch sensors
	======================== ======================================================

So, the concept of "V4L2 Device Node" is now clear, and doesn't
include V4L2 sub-device device nodes (/dev/v4l-subdev*).

For devices controlled via media controller, everybody seems to be
comfortable of calling them as MC-centric.

There are currently two proposals to refer to the media hardware that
is controlled via a V4L2 Device Node:

	- vdev-centric
	- V4L2-centric

The last one sounds confusing to me, as subdev API is part of the V4L2
specification. "V4L2-centric" name sounds to include subdevs. 

That's why IMHO, vdev-centric is better.

We could go to some other naming for them, that would also be
an alias for "V4L2 Device Node":

	- VD-centric
	- VDN-centric

Comments?

Thanks,
Mauro