* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Zach Brown @ 2015-05-07 17:20 UTC (permalink / raw)
To: Dave Chinner
Cc: Alexander Viro, Sage Weil, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150507002617.GJ4327@dastard>
On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
> On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
> > Add the O_NOMTIME flag which prevents mtime from being updated which can
> > greatly reduce the IO overhead of writes to allocated and initialized
> > regions of files.
>
> Hmmm. How do backup programs now work out if the file has changed
> and hence needs copying again? ie. applications using this will
> break other critical infrastructure in subtle ways.
By using backup infrastructure that doesn't use cmtime. Like btrfs
send/recv. Or application level backups that know how to do
incrementals from metadata in giant database files, say, without
walking, comparing, and copying the entire thing.
> > I opted not to name the flag O_NOCMTIME because I didn't want the name
> > to imply that ctime updates would be prevented for other inode changes
> > like updating i_size in truncate. Not updating ctime is a side-effect
> > of removing mtime updates when it's the only thing changing in the
> > inode.
>
> If adding this, wouldn't we want to unify O_NOMTIME and
> FMODE_NOCMTIME at the same time?
I could see that, sure.
> > The criteria for using O_NOMTIME is the same as for using O_NOATIME:
> > owning the file or having the CAP_FOWNER capability. If we're not
> > comfortable allowing owners to prevent mtime/ctime updates then we
> > should add a tunable to allow O_NOMTIME. Maybe a mount option?
>
> I dislike "turn off safety for performance" options because Joe
> SpeedRacer will always select performance over safety.
Well, for ceph there's no safety concern. They never use cmtime in
these files.
So are you suggesting not implementing this and making them rework their
IO paths to avoid the fs maintaining mtime so that we don't give Joe
Speedracer more rope? Or are we talking about adding some speed bumps
that ceph can flip on that might give Joe Speedracer pause?
- z
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Zach Brown @ 2015-05-07 18:43 UTC (permalink / raw)
To: Dave Chinner
Cc: Alexander Viro, Sage Weil, linux-fsdevel, linux-kernel, linux-api
In-Reply-To: <20150507172053.GA659@lenny.home.zabbo.net>
> > > The criteria for using O_NOMTIME is the same as for using O_NOATIME:
> > > owning the file or having the CAP_FOWNER capability. If we're not
> > > comfortable allowing owners to prevent mtime/ctime updates then we
> > > should add a tunable to allow O_NOMTIME. Maybe a mount option?
> >
> > I dislike "turn off safety for performance" options because Joe
> > SpeedRacer will always select performance over safety.
>
> Well, for ceph there's no safety concern. They never use cmtime in
> these files.
>
> So are you suggesting not implementing this and making them rework their
> IO paths to avoid the fs maintaining mtime so that we don't give Joe
> Speedracer more rope? Or are we talking about adding some speed bumps
> that ceph can flip on that might give Joe Speedracer pause?
Maybe one way to make it less of an attractive nuisance would be to hide
it under open_by_handle_at(). Like xfs_open_by_handle() does today but
we probably don't want to unconditionally add it to the generic path so
we'd have a flag.
They want to move to opening by handles anyway to avoid dirent lookups
when opening cold files.
- z
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Richard Weinberger @ 2015-05-07 19:09 UTC (permalink / raw)
To: Zach Brown
Cc: Dave Chinner, Alexander Viro, Sage Weil, linux-fsdevel, LKML,
open list:ABI/API
In-Reply-To: <20150507172053.GA659-fypN+1c5dIyjpB87vu3CluTW4wlIGRCZ@public.gmane.org>
On Thu, May 7, 2015 at 7:20 PM, Zach Brown <zab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
>> On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
>> > Add the O_NOMTIME flag which prevents mtime from being updated which can
>> > greatly reduce the IO overhead of writes to allocated and initialized
>> > regions of files.
>>
>> Hmmm. How do backup programs now work out if the file has changed
>> and hence needs copying again? ie. applications using this will
>> break other critical infrastructure in subtle ways.
>
> By using backup infrastructure that doesn't use cmtime. Like btrfs
> send/recv. Or application level backups that know how to do
> incrementals from metadata in giant database files, say, without
> walking, comparing, and copying the entire thing.
But how can Joey random user know that some of his
applications are using O_NOMTIME and his KISS backup
program does no longer function as expected?
--
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Andy Lutomirski @ 2015-05-07 19:53 UTC (permalink / raw)
To: Richard Weinberger
Cc: Zach Brown, Dave Chinner, Alexander Viro, Sage Weil,
linux-fsdevel, LKML, open list:ABI/API
In-Reply-To: <CAFLxGvw8ESrM6vZ4iB70JFQN-qR-Trs3j1O_+y36tSOn0GVH4A@mail.gmail.com>
On Thu, May 7, 2015 at 12:09 PM, Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> On Thu, May 7, 2015 at 7:20 PM, Zach Brown <zab@redhat.com> wrote:
>> On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
>>> On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
>>> > Add the O_NOMTIME flag which prevents mtime from being updated which can
>>> > greatly reduce the IO overhead of writes to allocated and initialized
>>> > regions of files.
>>>
>>> Hmmm. How do backup programs now work out if the file has changed
>>> and hence needs copying again? ie. applications using this will
>>> break other critical infrastructure in subtle ways.
>>
>> By using backup infrastructure that doesn't use cmtime. Like btrfs
>> send/recv. Or application level backups that know how to do
>> incrementals from metadata in giant database files, say, without
>> walking, comparing, and copying the entire thing.
>
> But how can Joey random user know that some of his
> applications are using O_NOMTIME and his KISS backup
> program does no longer function as expected?
>
Joey random user can't have a working KISS backup anyway, though,
because we screw up mtime updates on mmap writes. I have patches
gathering dust that fix that, though.
--Andy
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Andy Lutomirski @ 2015-05-07 20:06 UTC (permalink / raw)
To: Richard Weinberger
Cc: Zach Brown, Dave Chinner, Alexander Viro, Sage Weil,
linux-fsdevel, LKML, open list:ABI/API
In-Reply-To: <554BC4D8.9010507@nod.at>
On Thu, May 7, 2015 at 1:02 PM, Richard Weinberger <richard@nod.at> wrote:
> Am 07.05.2015 um 21:53 schrieb Andy Lutomirski:
>> On Thu, May 7, 2015 at 12:09 PM, Richard Weinberger
>> <richard.weinberger@gmail.com> wrote:
>>> On Thu, May 7, 2015 at 7:20 PM, Zach Brown <zab@redhat.com> wrote:
>>>> On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
>>>>> On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
>>>>>> Add the O_NOMTIME flag which prevents mtime from being updated which can
>>>>>> greatly reduce the IO overhead of writes to allocated and initialized
>>>>>> regions of files.
>>>>>
>>>>> Hmmm. How do backup programs now work out if the file has changed
>>>>> and hence needs copying again? ie. applications using this will
>>>>> break other critical infrastructure in subtle ways.
>>>>
>>>> By using backup infrastructure that doesn't use cmtime. Like btrfs
>>>> send/recv. Or application level backups that know how to do
>>>> incrementals from metadata in giant database files, say, without
>>>> walking, comparing, and copying the entire thing.
>>>
>>> But how can Joey random user know that some of his
>>> applications are using O_NOMTIME and his KISS backup
>>> program does no longer function as expected?
>>>
>>
>> Joey random user can't have a working KISS backup anyway, though,
>> because we screw up mtime updates on mmap writes. I have patches
>> gathering dust that fix that, though.
>
> Hmmm, I thought mtime will be updated upon msync()?
> Assuming a sane application is using msync()...
>
So would I. Unfortunately, mtime is updated on the page fault that
makes an mmapped page writeable, thus guaranteeing that the resulting
mtime is stale if you mmap a file, write to it, unmap it, and close
it. It's much more stale if you mmap it, write, wait for a while but
not long enough that the page is automatically written back, write
again, unmap, and close.
--Andy
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Sage Weil @ 2015-05-08 1:01 UTC (permalink / raw)
To: Zach Brown
Cc: Dave Chinner, Alexander Viro, linux-fsdevel, linux-kernel,
linux-api
In-Reply-To: <20150507172053.GA659@lenny.home.zabbo.net>
On Thu, 7 May 2015, Zach Brown wrote:
> On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
> > On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
> > > The criteria for using O_NOMTIME is the same as for using O_NOATIME:
> > > owning the file or having the CAP_FOWNER capability. If we're not
> > > comfortable allowing owners to prevent mtime/ctime updates then we
> > > should add a tunable to allow O_NOMTIME. Maybe a mount option?
> >
> > I dislike "turn off safety for performance" options because Joe
> > SpeedRacer will always select performance over safety.
>
> Well, for ceph there's no safety concern. They never use cmtime in
> these files.
>
> So are you suggesting not implementing this and making them rework their
> IO paths to avoid the fs maintaining mtime so that we don't give Joe
> Speedracer more rope? Or are we talking about adding some speed bumps
> that ceph can flip on that might give Joe Speedracer pause?
I think this is the fundamental question: who do we give the ammunition
to, the user or app writer, or the sysadmin?
One might argue that we gave the user a similar power with O_NOATIME (the
power to break applications that assume atime is accurate). Here we give
developers/users the power to not update mtime and suffer the consequences
(like, obviously, breaking mtime-based backups). It should be pretty
obvious to anyone using the flag what the consequences are.
Note that we can suffer similar lapses in mtime with fdatasync followed by
a system crash. And as Andy points out it's semi-broken for writable
mmap. The crash case is obviously a slightly different thing, but the
idea that mtime can't always be trusted certainly isn't crazy talk.
Or, we can be conservative and require a mount option so that the admin
has to explicitly allow behavior that might break some existing
assumptions about mtime/ctime ('-o user_noatime' I guess?).
I'm happy either way, so long as in the end an unprivileged ceph daemon
avoids the useless work. In our case we always own the entire mount/disk,
so a mount option is just fine.
Thanks!
sage
^ permalink raw reply
* [PATCH 02/18] media controller: deprecate entity subtype
From: Mauro Carvalho Chehab @ 2015-05-08 1:12 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-api
In-Reply-To: <cover.1431046915.git.mchehab@osg.samsung.com>
The media controller entity subtype doesn't make much sense,
especially since V4L2 subdevices may also have associated devnodes.
So, better to get rid of it while it is not too late.
We need, of course, to keep the old symbols to avoid userspace
breakage, but we should avoid using them internally at the
Kernel.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 4e816be3de39..775c11c6b173 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -42,31 +42,45 @@ struct media_device_info {
#define MEDIA_ENT_ID_FLAG_NEXT (1 << 31)
+/* Used values for media_entity_desc::type */
+
+#define MEDIA_ENT_T_DEVNODE_V4L (((1 << 16)) + 1)
+#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_DEVNODE_V4L + 3)
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX (MEDIA_ENT_T_DEVNODE_V4L + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR (MEDIA_ENT_T_DEVNODE_V4L + 5)
+#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_DEVNODE_V4L + 6)
+#define MEDIA_ENT_T_DEVNODE_DVB_NET (MEDIA_ENT_T_DEVNODE_V4L + 7)
+
+#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR ((2 << 16) + 1)
+#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH (MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 1)
+#define MEDIA_ENT_T_V4L2_SUBDEV_LENS (MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 2)
+/* A converter of analogue video to its digital representation. */
+#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 3)
+
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER (MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 4)
+
+#if 1
+/*
+ * Legacy symbols.
+ * Kept just to avoid userspace compilation breakages.
+ * One day, the symbols bellow will be removed
+ */
+
#define MEDIA_ENT_TYPE_SHIFT 16
#define MEDIA_ENT_TYPE_MASK 0x00ff0000
#define MEDIA_ENT_SUBTYPE_MASK 0x0000ffff
#define MEDIA_ENT_T_DEVNODE (1 << MEDIA_ENT_TYPE_SHIFT)
-#define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE + 1)
+#define MEDIA_ENT_T_V4L2_SUBDEV (2 << MEDIA_ENT_TYPE_SHIFT)
+
#define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2)
#define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_DEVNODE + 4)
-#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX (MEDIA_ENT_T_DEVNODE + 5)
-#define MEDIA_ENT_T_DEVNODE_DVB_DVR (MEDIA_ENT_T_DEVNODE + 6)
-#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_DEVNODE + 7)
-#define MEDIA_ENT_T_DEVNODE_DVB_NET (MEDIA_ENT_T_DEVNODE + 8)
-/* Legacy symbol. Use it to avoid userspace compilation breakages */
+
#define MEDIA_ENT_T_DEVNODE_DVB MEDIA_ENT_T_DEVNODE_DVB_FE
+#endif
-#define MEDIA_ENT_T_V4L2_SUBDEV (2 << MEDIA_ENT_TYPE_SHIFT)
-#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR (MEDIA_ENT_T_V4L2_SUBDEV + 1)
-#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH (MEDIA_ENT_T_V4L2_SUBDEV + 2)
-#define MEDIA_ENT_T_V4L2_SUBDEV_LENS (MEDIA_ENT_T_V4L2_SUBDEV + 3)
-/* A converter of analogue video to its digital representation. */
-#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_V4L2_SUBDEV + 4)
-
-#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER (MEDIA_ENT_T_V4L2_SUBDEV + 5)
+/* Used bitmasks for media_entity_desc::flags */
#define MEDIA_ENT_FL_DEFAULT (1 << 0)
--
2.1.0
^ permalink raw reply related
* [PATCH 03/18] media controller: use MEDIA_ENT_T_AV_DMA for A/V DMA engines
From: Mauro Carvalho Chehab @ 2015-05-08 1:12 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet,
Hyun Kwon, Laurent Pinchart, Michal Simek, Sören Brinkmann,
Hans Verkuil, Sakari Ailus, Sylwester Nawrocki,
Ramakrishnan Muthukrishnan, Markus Elfring,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1431046915.git.mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
At the Video4Linux API, the /dev/video?, /dev/vbi? and
/dev/radio? device nodes are used for the chipset that
provides the bridge between video/radio streams and the
USB, PCI or CPU buses.
Such bridge is also typically used to control the V4L2 device
as a hole.
For video streaming devices and SDR radio devices, they're
also associated with the DMA engines that transfer the
video stream (or SDR stream) to the CPU's memory.
It should be noticed, however, this is not true on non-SDR
radio devices, and may also not be true on embedded devices
that, due to DRM reasons, don't allow writing unencrypted
data on a memory that could be seen by the CPU.
So, we'll eventually need to add another entity for such
bridge chipsets that have a video/vbi/radio device node
associated, but don't have DMA engines on (some) devnodes.
As, currently, we don't have any such case, let's for now
just rename the device nodes that are associated with a
DMA engine as MEDIA_ENT_T_AV_DMA.
So,
MEDIA_ENT_T_DEVNODE_V4L -> MEDIA_ENT_T_AV_DMA
PS.: This is not actually true for USB devices, as the
DMA engine is an internal component, as it is up to the
Kernel to strip the stream payload from the URB packages.
Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 5872f8bbf774..5b8147629159 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -183,7 +183,7 @@
<entry>Unknown device node</entry>
</row>
<row>
- <entry><constant>MEDIA_ENT_T_DEVNODE_V4L</constant></entry>
+ <entry><constant>MEDIA_ENT_T_AV_DMA</constant></entry>
<entry>V4L video, radio or vbi device node</entry>
</row>
<row>
diff --git a/drivers/media/platform/xilinx/xilinx-dma.c b/drivers/media/platform/xilinx/xilinx-dma.c
index efde88adf624..7fa0cc0f08f0 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -193,7 +193,7 @@ static int xvip_pipeline_validate(struct xvip_pipeline *pipe,
while ((entity = media_entity_graph_walk_next(&graph))) {
struct xvip_dma *dma;
- if (entity->type != MEDIA_ENT_T_DEVNODE_V4L)
+ if (entity->type != MEDIA_ENT_T_AV_DMA)
continue;
dma = to_xvip_dma(media_entity_to_video_device(entity));
diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c
index 71a1b93b0790..9ef920221b5a 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -912,7 +912,7 @@ int __video_register_device(struct video_device *vdev, int type, int nr,
/* Part 5: Register the entity. */
if (vdev->v4l2_dev->mdev &&
vdev->vfl_type != VFL_TYPE_SUBDEV) {
- vdev->entity.type = MEDIA_ENT_T_DEVNODE_V4L;
+ vdev->entity.type = MEDIA_ENT_T_AV_DMA;
vdev->entity.name = vdev->name;
vdev->entity.info.dev.major = VIDEO_MAJOR;
vdev->entity.info.dev.minor = vdev->minor;
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c
index 63596063b213..9f8fc8330b3e 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -535,7 +535,7 @@ v4l2_subdev_link_validate_get_format(struct media_pad *pad,
return v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt);
}
- WARN(pad->entity->type != MEDIA_ENT_T_DEVNODE_V4L,
+ WARN(pad->entity->type != MEDIA_ENT_T_AV_DMA,
"Driver bug! Wrong media entity type 0x%08x, entity %s\n",
pad->entity->type, pad->entity->name);
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 775c11c6b173..a7aa2aac9c23 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -44,12 +44,12 @@ struct media_device_info {
/* Used values for media_entity_desc::type */
-#define MEDIA_ENT_T_DEVNODE_V4L (((1 << 16)) + 1)
-#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_DEVNODE_V4L + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX (MEDIA_ENT_T_DEVNODE_V4L + 4)
-#define MEDIA_ENT_T_DEVNODE_DVB_DVR (MEDIA_ENT_T_DEVNODE_V4L + 5)
-#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_DEVNODE_V4L + 6)
-#define MEDIA_ENT_T_DEVNODE_DVB_NET (MEDIA_ENT_T_DEVNODE_V4L + 7)
+#define MEDIA_ENT_T_AV_DMA (((1 << 16)) + 1)
+#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_AV_DMA + 3)
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX (MEDIA_ENT_T_AV_DMA + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR (MEDIA_ENT_T_AV_DMA + 5)
+#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_AV_DMA + 6)
+#define MEDIA_ENT_T_DEVNODE_DVB_NET (MEDIA_ENT_T_AV_DMA + 7)
#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR ((2 << 16) + 1)
#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH (MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 1)
--
2.1.0
^ permalink raw reply related
* [PATCH 04/18] media controller: Rename camera entities
From: Mauro Carvalho Chehab @ 2015-05-08 1:12 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet,
Sakari Ailus, Laurent Pinchart, Kyungmin Park, Heungjun Kim,
Prabhakar Lad, Andrzej Hajda, Hans Verkuil, Sylwester Nawrocki,
Boris BREZILLON, linux-doc, linux-api
In-Reply-To: <cover.1431046915.git.mchehab@osg.samsung.com>
As explained before, the hole idea of subtypes at entities was
not nice. All V4L2 subdevs may have a device node associated.
Also, the hole idea is to expose hardware IP blocks, so calling
them as V4L2 is a very bad practice, as they were not designed
for the V4L2 API. It is just the reverse.
So, instead of using V4L2_SUBDEV, let's call the camera sub-
devices with CAM, instead:
MEDIA_ENT_T_V4L2_SUBDEV_SENSOR -> MEDIA_ENT_T_CAM_SENSOR
MEDIA_ENT_T_V4L2_SUBDEV_FLASH -> MEDIA_ENT_T_CAM_FLASH
MEDIA_ENT_T_V4L2_SUBDEV_LENS -> MEDIA_ENT_T_CAM_LENS
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 5b8147629159..759604e3529f 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -219,15 +219,15 @@
<entry>Unknown V4L sub-device</entry>
</row>
<row>
- <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_SENSOR</constant></entry>
+ <entry><constant>MEDIA_ENT_T_CAM_SENSOR</constant></entry>
<entry>Video sensor</entry>
</row>
<row>
- <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_FLASH</constant></entry>
+ <entry><constant>MEDIA_ENT_T_CAM_FLASH</constant></entry>
<entry>Flash controller</entry>
</row>
<row>
- <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry>
+ <entry><constant>MEDIA_ENT_T_CAM_LENS</constant></entry>
<entry>Lens controller</entry>
</row>
<row>
diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index c70ababce954..c12f873a8e26 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -516,7 +516,7 @@ static int adp1653_probe(struct i2c_client *client,
if (ret < 0)
goto free_and_quit;
- flash->subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
+ flash->subdev.entity.type = MEDIA_ENT_T_CAM_FLASH;
return 0;
diff --git a/drivers/media/i2c/as3645a.c b/drivers/media/i2c/as3645a.c
index 301084b07887..9a2872be11b0 100644
--- a/drivers/media/i2c/as3645a.c
+++ b/drivers/media/i2c/as3645a.c
@@ -831,7 +831,7 @@ static int as3645a_probe(struct i2c_client *client,
if (ret < 0)
goto done;
- flash->subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
+ flash->subdev.entity.type = MEDIA_ENT_T_CAM_FLASH;
mutex_init(&flash->power_lock);
diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
index d9ece4b2d047..4d28cda77f4d 100644
--- a/drivers/media/i2c/lm3560.c
+++ b/drivers/media/i2c/lm3560.c
@@ -368,7 +368,7 @@ static int lm3560_subdev_init(struct lm3560_flash *flash,
rval = media_entity_init(&flash->subdev_led[led_no].entity, 0, NULL, 0);
if (rval < 0)
goto err_out;
- flash->subdev_led[led_no].entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
+ flash->subdev_led[led_no].entity.type = MEDIA_ENT_T_CAM_FLASH;
return rval;
diff --git a/drivers/media/i2c/lm3646.c b/drivers/media/i2c/lm3646.c
index 626fb4679c02..19ee2ac00be7 100644
--- a/drivers/media/i2c/lm3646.c
+++ b/drivers/media/i2c/lm3646.c
@@ -285,7 +285,7 @@ static int lm3646_subdev_init(struct lm3646_flash *flash)
rval = media_entity_init(&flash->subdev_led.entity, 0, NULL, 0);
if (rval < 0)
goto err_out;
- flash->subdev_led.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
+ flash->subdev_led.entity.type = MEDIA_ENT_T_CAM_FLASH;
return rval;
err_out:
diff --git a/drivers/media/i2c/m5mols/m5mols_core.c b/drivers/media/i2c/m5mols/m5mols_core.c
index 6404c0d93e7a..beb519cf8be4 100644
--- a/drivers/media/i2c/m5mols/m5mols_core.c
+++ b/drivers/media/i2c/m5mols/m5mols_core.c
@@ -978,7 +978,7 @@ static int m5mols_probe(struct i2c_client *client,
ret = media_entity_init(&sd->entity, 1, &info->pad, 0);
if (ret < 0)
return ret;
- sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+ sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
init_waitqueue_head(&info->irq_waitq);
mutex_init(&info->lock);
diff --git a/drivers/media/i2c/noon010pc30.c b/drivers/media/i2c/noon010pc30.c
index f197b6cbd407..a03556197405 100644
--- a/drivers/media/i2c/noon010pc30.c
+++ b/drivers/media/i2c/noon010pc30.c
@@ -779,7 +779,7 @@ static int noon010_probe(struct i2c_client *client,
goto np_err;
info->pad.flags = MEDIA_PAD_FL_SOURCE;
- sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+ sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
ret = media_entity_init(&sd->entity, 1, &info->pad, 0);
if (ret < 0)
goto np_err;
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index d700a1d0a6f2..63b9464e813f 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -1425,7 +1425,7 @@ static int ov2659_probe(struct i2c_client *client,
#if defined(CONFIG_MEDIA_CONTROLLER)
ov2659->pad.flags = MEDIA_PAD_FL_SOURCE;
- sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+ sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
ret = media_entity_init(&sd->entity, 1, &ov2659->pad, 0);
if (ret < 0) {
v4l2_ctrl_handler_free(&ov2659->ctrls);
diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 2bc473385c91..ed3c0573a0f8 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -1500,7 +1500,7 @@ static int ov965x_probe(struct i2c_client *client,
return ret;
ov965x->pad.flags = MEDIA_PAD_FL_SOURCE;
- sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+ sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
ret = media_entity_init(&sd->entity, 1, &ov965x->pad, 0);
if (ret < 0)
return ret;
diff --git a/drivers/media/i2c/s5k4ecgx.c b/drivers/media/i2c/s5k4ecgx.c
index 97084237275d..23af7f90678a 100644
--- a/drivers/media/i2c/s5k4ecgx.c
+++ b/drivers/media/i2c/s5k4ecgx.c
@@ -961,7 +961,7 @@ static int s5k4ecgx_probe(struct i2c_client *client,
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
priv->pad.flags = MEDIA_PAD_FL_SOURCE;
- sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+ sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
ret = media_entity_init(&sd->entity, 1, &priv->pad, 0);
if (ret)
return ret;
diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
index bee73de347dc..fadd48d35a55 100644
--- a/drivers/media/i2c/s5k5baf.c
+++ b/drivers/media/i2c/s5k5baf.c
@@ -408,7 +408,7 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct v4l2_ctrl *ctrl)
static inline bool s5k5baf_is_cis_subdev(struct v4l2_subdev *sd)
{
- return sd->entity.type == MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+ return sd->entity.type == MEDIA_ENT_T_CAM_SENSOR;
}
static inline struct s5k5baf *to_s5k5baf(struct v4l2_subdev *sd)
@@ -1904,7 +1904,7 @@ static int s5k5baf_configure_subdevs(struct s5k5baf *state,
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
state->cis_pad.flags = MEDIA_PAD_FL_SOURCE;
- sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+ sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
ret = media_entity_init(&sd->entity, NUM_CIS_PADS, &state->cis_pad, 0);
if (ret < 0)
goto err;
diff --git a/drivers/media/i2c/s5k6aa.c b/drivers/media/i2c/s5k6aa.c
index d0ad6a25bdab..d2390c6e5dbe 100644
--- a/drivers/media/i2c/s5k6aa.c
+++ b/drivers/media/i2c/s5k6aa.c
@@ -1577,7 +1577,7 @@ static int s5k6aa_probe(struct i2c_client *client,
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
s5k6aa->pad.flags = MEDIA_PAD_FL_SOURCE;
- sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+ sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
ret = media_entity_init(&sd->entity, 1, &s5k6aa->pad, 0);
if (ret)
return ret;
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c
index 636ebd6fe5dc..78f2cdd3561b 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2763,7 +2763,7 @@ static int smiapp_init(struct smiapp_sensor *sensor)
dev_dbg(&client->dev, "profile %d\n", sensor->minfo.smiapp_profile);
- sensor->pixel_array->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+ sensor->pixel_array->sd.entity.type = MEDIA_ENT_T_CAM_SENSOR;
/* final steps */
smiapp_read_frame_fmt(sensor);
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index a7aa2aac9c23..2e465ba087ba 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -51,13 +51,13 @@ struct media_device_info {
#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_AV_DMA + 6)
#define MEDIA_ENT_T_DEVNODE_DVB_NET (MEDIA_ENT_T_AV_DMA + 7)
-#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR ((2 << 16) + 1)
-#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH (MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 1)
-#define MEDIA_ENT_T_V4L2_SUBDEV_LENS (MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 2)
+#define MEDIA_ENT_T_CAM_SENSOR ((2 << 16) + 1)
+#define MEDIA_ENT_T_CAM_FLASH (MEDIA_ENT_T_CAM_SENSOR + 1)
+#define MEDIA_ENT_T_CAM_LENS (MEDIA_ENT_T_CAM_SENSOR + 2)
/* A converter of analogue video to its digital representation. */
-#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 3)
+#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_CAM_SENSOR + 3)
-#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER (MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 4)
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER (MEDIA_ENT_T_CAM_SENSOR + 4)
#if 1
/*
@@ -76,8 +76,10 @@ struct media_device_info {
#define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2)
#define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3)
-
#define MEDIA_ENT_T_DEVNODE_DVB MEDIA_ENT_T_DEVNODE_DVB_FE
+#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR MEDIA_ENT_T_CAM_SENSOR
+#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH MEDIA_ENT_T_CAM_FLASH
+#define MEDIA_ENT_T_V4L2_SUBDEV_LENS MEDIA_ENT_T_CAM_LENS
#endif
/* Used bitmasks for media_entity_desc::flags */
--
2.1.0
^ permalink raw reply related
* [PATCH 05/18] media controller: rename MEDIA_ENT_T_DEVNODE_DVB entities
From: Mauro Carvalho Chehab @ 2015-05-08 1:12 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet,
Hans Verkuil, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1431046915.git.mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
In order to reflect that the entities are actually the hardware
(or firmware, or in-kernel software), and are not associated
with the DVB API, let's remove DEVNODE_ from the entity names
and use DTV (Digital TV) for the entities.
The frontend is an special case: the frontend devnode actually
talks directly with the DTV demodulator. It may or may not also
talk with the SEC (Satellite Equipment Control) and with the
tuner. For the sake of unifying the nomenclature, let's call it
as MEDIA_ENT_T_DTV_DEMOD, because this component is always
there.
So:
MEDIA_ENT_T_DEVNODE_DVB_FE -> MEDIA_ENT_T_DTV_DEMOD
MEDIA_ENT_T_DEVNODE_DVB_DEMUX -> MEDIA_ENT_T_DTV_DEMUX
MEDIA_ENT_T_DEVNODE_DVB_DVR -> MEDIA_ENT_T_DTV_DVR
MEDIA_ENT_T_DEVNODE_DVB_CA -> MEDIA_ENT_T_DTV_CA
MEDIA_ENT_T_DEVNODE_DVB_NET -> MEDIA_ENT_T_DTV_NET
PS.: we could actually not keep this define:
#define MEDIA_ENT_T_DEVNODE_DVB_FE MEDIA_ENT_T_DTV_DEMOD
As MEDIA_ENT_T_DEVNODE_DVB_FE symbol will not arrive any Kernel
version (being present only at the 4.1-rc kernels), but keeping
it helps to show that the DVB frontend node is actually associated
with the DTV demodulator. So, keeping it for now helps to better
document. Also, it avoids to break experimental versions of v4l-utils.
So, better to remove this only when we remove the remaining legacy
stuff.
Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 759604e3529f..27082b07f4c2 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -195,23 +195,23 @@
<entry>ALSA card</entry>
</row>
<row>
- <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_FE</constant></entry>
+ <entry><constant>MEDIA_ENT_T_DTV_DEMOD</constant></entry>
<entry>DVB frontend devnode</entry>
</row>
<row>
- <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DEMUX</constant></entry>
+ <entry><constant>MEDIA_ENT_T_DTV_DEMUX</constant></entry>
<entry>DVB demux devnode</entry>
</row>
<row>
- <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DVR</constant></entry>
+ <entry><constant>MEDIA_ENT_T_DTV_DVR</constant></entry>
<entry>DVB DVR devnode</entry>
</row>
<row>
- <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_CA</constant></entry>
+ <entry><constant>MEDIA_ENT_T_DTV_CA</constant></entry>
<entry>DVB CAM devnode</entry>
</row>
<row>
- <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_NET</constant></entry>
+ <entry><constant>MEDIA_ENT_T_DTV_NET</constant></entry>
<entry>DVB network devnode</entry>
</row>
<row>
diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 13bb57f0457f..39846077045e 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -221,26 +221,26 @@ static void dvb_register_media_device(struct dvb_device *dvbdev,
switch (type) {
case DVB_DEVICE_FRONTEND:
- dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_FE;
+ dvbdev->entity->type = MEDIA_ENT_T_DTV_DEMOD;
dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
dvbdev->pads[1].flags = MEDIA_PAD_FL_SOURCE;
break;
case DVB_DEVICE_DEMUX:
- dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_DEMUX;
+ dvbdev->entity->type = MEDIA_ENT_T_DTV_DEMUX;
dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
dvbdev->pads[1].flags = MEDIA_PAD_FL_SOURCE;
break;
case DVB_DEVICE_DVR:
- dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_DVR;
+ dvbdev->entity->type = MEDIA_ENT_T_DTV_DVR;
dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
break;
case DVB_DEVICE_CA:
- dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_CA;
+ dvbdev->entity->type = MEDIA_ENT_T_DTV_CA;
dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
dvbdev->pads[1].flags = MEDIA_PAD_FL_SOURCE;
break;
case DVB_DEVICE_NET:
- dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_NET;
+ dvbdev->entity->type = MEDIA_ENT_T_DTV_NET;
break;
default:
kfree(dvbdev->entity);
@@ -396,16 +396,16 @@ void dvb_create_media_graph(struct dvb_adapter *adap)
case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
tuner = entity;
break;
- case MEDIA_ENT_T_DEVNODE_DVB_FE:
+ case MEDIA_ENT_T_DTV_DEMOD:
fe = entity;
break;
- case MEDIA_ENT_T_DEVNODE_DVB_DEMUX:
+ case MEDIA_ENT_T_DTV_DEMUX:
demux = entity;
break;
- case MEDIA_ENT_T_DEVNODE_DVB_DVR:
+ case MEDIA_ENT_T_DTV_DVR:
dvr = entity;
break;
- case MEDIA_ENT_T_DEVNODE_DVB_CA:
+ case MEDIA_ENT_T_DTV_CA:
ca = entity;
break;
}
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 2e465ba087ba..0de9912411c5 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -45,11 +45,11 @@ struct media_device_info {
/* Used values for media_entity_desc::type */
#define MEDIA_ENT_T_AV_DMA (((1 << 16)) + 1)
-#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_AV_DMA + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX (MEDIA_ENT_T_AV_DMA + 4)
-#define MEDIA_ENT_T_DEVNODE_DVB_DVR (MEDIA_ENT_T_AV_DMA + 5)
-#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_AV_DMA + 6)
-#define MEDIA_ENT_T_DEVNODE_DVB_NET (MEDIA_ENT_T_AV_DMA + 7)
+#define MEDIA_ENT_T_DTV_DEMOD (MEDIA_ENT_T_AV_DMA + 3)
+#define MEDIA_ENT_T_DTV_DEMUX (MEDIA_ENT_T_AV_DMA + 4)
+#define MEDIA_ENT_T_DTV_DVR (MEDIA_ENT_T_AV_DMA + 5)
+#define MEDIA_ENT_T_DTV_CA (MEDIA_ENT_T_AV_DMA + 6)
+#define MEDIA_ENT_T_DTV_NET (MEDIA_ENT_T_AV_DMA + 7)
#define MEDIA_ENT_T_CAM_SENSOR ((2 << 16) + 1)
#define MEDIA_ENT_T_CAM_FLASH (MEDIA_ENT_T_CAM_SENSOR + 1)
@@ -76,7 +76,13 @@ struct media_device_info {
#define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2)
#define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB MEDIA_ENT_T_DEVNODE_DVB_FE
+#define MEDIA_ENT_T_DEVNODE_DVB MEDIA_ENT_T_DTV_DEMOD
+#define MEDIA_ENT_T_DEVNODE_DVB_FE MEDIA_ENT_T_DTV_DEMOD
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX MEDIA_ENT_T_DTV_DEMUX
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR MEDIA_ENT_T_DTV_DVR
+#define MEDIA_ENT_T_DEVNODE_DVB_CA MEDIA_ENT_T_DTV_CA
+#define MEDIA_ENT_T_DEVNODE_DVB_NET MEDIA_ENT_T_DTV_NET
+
#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR MEDIA_ENT_T_CAM_SENSOR
#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH MEDIA_ENT_T_CAM_FLASH
#define MEDIA_ENT_T_V4L2_SUBDEV_LENS MEDIA_ENT_T_CAM_LENS
--
2.1.0
^ permalink raw reply related
* [PATCH 06/18] media controller: rename analog TV decoder
From: Mauro Carvalho Chehab @ 2015-05-08 1:12 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet,
Lars-Peter Clausen, Hans Verkuil, Prabhakar Lad, Sakari Ailus,
Joe Perches, Boris BREZILLON, Laurent Pinchart,
Guennadi Liakhovetski, Axel Lin, Matthias Schwarzott,
Antti Palosaari, Olli Salonen, Peter Senna Tschudin,
Ramakrishnan Muthukrishnan, linux-doc, linux-api
In-Reply-To: <cover.1431046915.git.mchehab@osg.samsung.com>
To keep coherency, let's also remove V4L2_SUBDEV from the analog
TV decoder, calling it by its function, and not by the V4L2
API mapping.
So,
MEDIA_ENT_T_V4L2_SUBDEV_DECODER -> MEDIA_ENT_T_ATV_DECODER
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 27082b07f4c2..9b3861058f0d 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -231,7 +231,7 @@
<entry>Lens controller</entry>
</row>
<row>
- <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_DECODER</constant></entry>
+ <entry><constant>MEDIA_ENT_T_ATV_DECODER</constant></entry>
<entry>Video decoder, the basic function of the video decoder is to
accept analogue video from a wide variety of sources such as
broadcast, DVD players, cameras and video cassette recorders, in
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index a493c0b0b5fe..e8f0b53cc253 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -1212,7 +1212,7 @@ static int adv7180_probe(struct i2c_client *client,
goto err_unregister_vpp_client;
state->pad.flags = MEDIA_PAD_FL_SOURCE;
- sd->entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+ sd->entity.flags |= MEDIA_ENT_T_ATV_DECODER;
ret = media_entity_init(&sd->entity, 1, &state->pad, 0);
if (ret)
goto err_free_ctrl;
diff --git a/drivers/media/i2c/cx25840/cx25840-core.c b/drivers/media/i2c/cx25840/cx25840-core.c
index e15a789ad596..cd8a3c273ab8 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -5208,7 +5208,7 @@ static int cx25840_probe(struct i2c_client *client,
state->pads[CX25840_PAD_INPUT].flags = MEDIA_PAD_FL_SINK;
state->pads[CX25840_PAD_VID_OUT].flags = MEDIA_PAD_FL_SOURCE;
state->pads[CX25840_PAD_VBI_OUT].flags = MEDIA_PAD_FL_SOURCE;
- sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+ sd->entity.type = MEDIA_ENT_T_ATV_DECODER;
ret = media_entity_init(&sd->entity, ARRAY_SIZE(state->pads),
state->pads, 0);
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index 24e47279e30c..77744c390941 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -1106,7 +1106,7 @@ tvp514x_probe(struct i2c_client *client, const struct i2c_device_id *id)
#if defined(CONFIG_MEDIA_CONTROLLER)
decoder->pad.flags = MEDIA_PAD_FL_SOURCE;
decoder->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
- decoder->sd.entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+ decoder->sd.entity.flags |= MEDIA_ENT_T_ATV_DECODER;
ret = media_entity_init(&decoder->sd.entity, 1, &decoder->pad, 0);
if (ret < 0) {
diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
index 05077cffd235..3facef49aef1 100644
--- a/drivers/media/i2c/tvp7002.c
+++ b/drivers/media/i2c/tvp7002.c
@@ -1019,7 +1019,7 @@ static int tvp7002_probe(struct i2c_client *c, const struct i2c_device_id *id)
#if defined(CONFIG_MEDIA_CONTROLLER)
device->pad.flags = MEDIA_PAD_FL_SOURCE;
device->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
- device->sd.entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+ device->sd.entity.flags |= MEDIA_ENT_T_ATV_DECODER;
error = media_entity_init(&device->sd.entity, 1, &device->pad, 0);
if (error < 0)
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c b/drivers/media/usb/cx231xx/cx231xx-cards.c
index fe00da105e77..a756f74f0adc 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1216,7 +1216,7 @@ static void cx231xx_create_media_graph(struct cx231xx *dev)
case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
tuner = entity;
break;
- case MEDIA_ENT_T_V4L2_SUBDEV_DECODER:
+ case MEDIA_ENT_T_ATV_DECODER:
decoder = entity;
break;
}
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c b/drivers/media/usb/cx231xx/cx231xx-video.c
index af44f2d1c0a1..bed4ee28916d 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -119,7 +119,7 @@ static int cx231xx_enable_analog_tuner(struct cx231xx *dev)
* this should be enough for the actual needs.
*/
media_device_for_each_entity(entity, mdev) {
- if (entity->type == MEDIA_ENT_T_V4L2_SUBDEV_DECODER) {
+ if (entity->type == MEDIA_ENT_T_ATV_DECODER) {
decoder = entity;
break;
}
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 0de9912411c5..9b3d80e765f0 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -54,8 +54,8 @@ struct media_device_info {
#define MEDIA_ENT_T_CAM_SENSOR ((2 << 16) + 1)
#define MEDIA_ENT_T_CAM_FLASH (MEDIA_ENT_T_CAM_SENSOR + 1)
#define MEDIA_ENT_T_CAM_LENS (MEDIA_ENT_T_CAM_SENSOR + 2)
-/* A converter of analogue video to its digital representation. */
-#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_CAM_SENSOR + 3)
+
+#define MEDIA_ENT_T_ATV_DECODER (MEDIA_ENT_T_CAM_SENSOR + 3)
#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER (MEDIA_ENT_T_CAM_SENSOR + 4)
@@ -86,6 +86,8 @@ struct media_device_info {
#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR MEDIA_ENT_T_CAM_SENSOR
#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH MEDIA_ENT_T_CAM_FLASH
#define MEDIA_ENT_T_V4L2_SUBDEV_LENS MEDIA_ENT_T_CAM_LENS
+
+#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER MEDIA_ENT_T_ATV_DECODER
#endif
/* Used bitmasks for media_entity_desc::flags */
--
2.1.0
^ permalink raw reply related
* [PATCH 07/18] media controller: rename the tuner entity
From: Mauro Carvalho Chehab @ 2015-05-08 1:12 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet,
Hans Verkuil, Matthias Schwarzott, Antti Palosaari, Olli Salonen,
Prabhakar Lad, Sakari Ailus, Laurent Pinchart, linux-doc,
linux-api
In-Reply-To: <cover.1431046915.git.mchehab@osg.samsung.com>
Finally, let's rename the tuner entity. inside the media subsystem,
a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV.
It could even be used on other subsystems, like network, for wireless
devices.
So, it is not constricted to V4L2 API, or to a subdev.
Let's then rename it as:
MEDIA_ENT_T_V4L2_SUBDEV_TUNER -> MEDIA_ENT_T_TUNER
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 9b3861058f0d..5c7f366bb1f4 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -241,7 +241,7 @@
signals.</entry>
</row>
<row>
- <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_TUNER</constant></entry>
+ <entry><constant>MEDIA_ENT_T_TUNER</constant></entry>
<entry>TV and/or radio tuner</entry>
</row>
</tbody>
diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 39846077045e..d6a096495035 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -393,7 +393,7 @@ void dvb_create_media_graph(struct dvb_adapter *adap)
media_device_for_each_entity(entity, mdev) {
switch (entity->type) {
- case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
+ case MEDIA_ENT_T_TUNER:
tuner = entity;
break;
case MEDIA_ENT_T_DTV_DEMOD:
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c b/drivers/media/usb/cx231xx/cx231xx-cards.c
index a756f74f0adc..2a7331e3c4a0 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1213,7 +1213,7 @@ static void cx231xx_create_media_graph(struct cx231xx *dev)
media_device_for_each_entity(entity, mdev) {
switch (entity->type) {
- case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
+ case MEDIA_ENT_T_TUNER:
tuner = entity;
break;
case MEDIA_ENT_T_ATV_DECODER:
diff --git a/drivers/media/v4l2-core/tuner-core.c b/drivers/media/v4l2-core/tuner-core.c
index abdcffabcb59..ecf4e8a543b3 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -696,7 +696,7 @@ static int tuner_probe(struct i2c_client *client,
register_client:
#if defined(CONFIG_MEDIA_CONTROLLER)
t->pad.flags = MEDIA_PAD_FL_SOURCE;
- t->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_TUNER;
+ t->sd.entity.type = MEDIA_ENT_T_TUNER;
t->sd.entity.name = t->name;
ret = media_entity_init(&t->sd.entity, 1, &t->pad, 0);
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 9b3d80e765f0..6acc4be1378c 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -57,7 +57,7 @@ struct media_device_info {
#define MEDIA_ENT_T_ATV_DECODER (MEDIA_ENT_T_CAM_SENSOR + 3)
-#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER (MEDIA_ENT_T_CAM_SENSOR + 4)
+#define MEDIA_ENT_T_TUNER (MEDIA_ENT_T_CAM_SENSOR + 4)
#if 1
/*
@@ -88,6 +88,8 @@ struct media_device_info {
#define MEDIA_ENT_T_V4L2_SUBDEV_LENS MEDIA_ENT_T_CAM_LENS
#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER MEDIA_ENT_T_ATV_DECODER
+
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER MEDIA_ENT_T_TUNER
#endif
/* Used bitmasks for media_entity_desc::flags */
--
2.1.0
^ permalink raw reply related
* [PATCH 08/18] media controller: add comments for the entity types
From: Mauro Carvalho Chehab @ 2015-05-08 1:12 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-api
In-Reply-To: <cover.1431046915.git.mchehab@osg.samsung.com>
Better document the linux/media.h UAPI header, by adding
comments to each entity subtype.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 6acc4be1378c..8d47b70b7ea8 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -44,19 +44,25 @@ struct media_device_info {
/* Used values for media_entity_desc::type */
+/* Audio/video streaming bridges */
#define MEDIA_ENT_T_AV_DMA (((1 << 16)) + 1)
+
+/* Digital TV entities */
#define MEDIA_ENT_T_DTV_DEMOD (MEDIA_ENT_T_AV_DMA + 3)
#define MEDIA_ENT_T_DTV_DEMUX (MEDIA_ENT_T_AV_DMA + 4)
#define MEDIA_ENT_T_DTV_DVR (MEDIA_ENT_T_AV_DMA + 5)
#define MEDIA_ENT_T_DTV_CA (MEDIA_ENT_T_AV_DMA + 6)
#define MEDIA_ENT_T_DTV_NET (MEDIA_ENT_T_AV_DMA + 7)
+/* Camera entities */
#define MEDIA_ENT_T_CAM_SENSOR ((2 << 16) + 1)
#define MEDIA_ENT_T_CAM_FLASH (MEDIA_ENT_T_CAM_SENSOR + 1)
#define MEDIA_ENT_T_CAM_LENS (MEDIA_ENT_T_CAM_SENSOR + 2)
+/* Analog TV entities */
#define MEDIA_ENT_T_ATV_DECODER (MEDIA_ENT_T_CAM_SENSOR + 3)
+/* Radio, Analog TV and/or Digital TV tuners */
#define MEDIA_ENT_T_TUNER (MEDIA_ENT_T_CAM_SENSOR + 4)
#if 1
--
2.1.0
^ permalink raw reply related
* [PATCH 16/18] v4l2-subdev: use MEDIA_ENT_T_UNKNOWN for new subdevs
From: Mauro Carvalho Chehab @ 2015-05-08 1:12 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Laurent Pinchart,
Hans Verkuil, Sakari Ailus, Sylwester Nawrocki, Markus Elfring,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1431046915.git.mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Instead of abusing MEDIA_ENT_T_V4L2_SUBDEV, initialize
new subdev entities as MEDIA_ENT_T_UNKNOWN.
Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c
index 66c6d9fd2033..0233d30b4922 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -584,7 +584,7 @@ void v4l2_subdev_init(struct v4l2_subdev *sd, const struct v4l2_subdev_ops *ops)
sd->host_priv = NULL;
#if defined(CONFIG_MEDIA_CONTROLLER)
sd->entity.name = sd->name;
- sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV;
+ sd->entity.type = MEDIA_ENT_T_UNKNOWN;
#endif
}
EXPORT_SYMBOL(v4l2_subdev_init);
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 8d47b70b7ea8..663eb2c6019d 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -44,6 +44,12 @@ struct media_device_info {
/* Used values for media_entity_desc::type */
+/*
+ * Initial value when an entity is created
+ * Drivers should change it to something useful
+ */
+#define MEDIA_ENT_T_UNKNOWN 0
+
/* Audio/video streaming bridges */
#define MEDIA_ENT_T_AV_DMA (((1 << 16)) + 1)
--
2.1.0
^ permalink raw reply related
* [PATCH 17/18] media controller: get rid of entity subtype on Kernel
From: Mauro Carvalho Chehab @ 2015-05-08 1:12 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-api
In-Reply-To: <cover.1431046915.git.mchehab@osg.samsung.com>
Don't use anymore the type/subtype entity data/macros
inside the Kernel.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index f15b48145711..bb98506532ff 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -103,16 +103,6 @@ struct media_entity {
} info;
};
-static inline u32 media_entity_type(struct media_entity *entity)
-{
- return entity->type & MEDIA_ENT_TYPE_MASK;
-}
-
-static inline u32 media_entity_subtype(struct media_entity *entity)
-{
- return entity->type & MEDIA_ENT_SUBTYPE_MASK;
-}
-
static inline bool is_media_entity_av_dma(struct media_entity *entity)
{
if (!entity)
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 663eb2c6019d..307cc4d72af0 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -71,7 +71,9 @@ struct media_device_info {
/* Radio, Analog TV and/or Digital TV tuners */
#define MEDIA_ENT_T_TUNER (MEDIA_ENT_T_CAM_SENSOR + 4)
-#if 1
+#define MEDIA_ENT_T_DEVNODE (1 << MEDIA_ENT_TYPE_SHIFT)
+
+#ifndef __KERNEL__
/*
* Legacy symbols.
* Kept just to avoid userspace compilation breakages.
@@ -82,7 +84,6 @@ struct media_device_info {
#define MEDIA_ENT_TYPE_MASK 0x00ff0000
#define MEDIA_ENT_SUBTYPE_MASK 0x0000ffff
-#define MEDIA_ENT_T_DEVNODE (1 << MEDIA_ENT_TYPE_SHIFT)
#define MEDIA_ENT_T_V4L2_SUBDEV (2 << MEDIA_ENT_TYPE_SHIFT)
#define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2)
--
2.1.0
^ permalink raw reply related
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Trond Myklebust @ 2015-05-08 1:23 UTC (permalink / raw)
To: Sage Weil
Cc: Zach Brown, Dave Chinner, Alexander Viro,
Linux FS-devel Mailing List, Linux Kernel Mailing List,
Linux API Mailing List
In-Reply-To: <alpine.DEB.2.00.1505071752520.28239-vIokxiIdD2AQNTJnQDzGJqxOck334EZe@public.gmane.org>
On Thu, May 7, 2015 at 9:01 PM, Sage Weil <sage-BnTBU8nroG7k1uMJSBkQmQ@public.gmane.org> wrote:
> On Thu, 7 May 2015, Zach Brown wrote:
>> On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
>> > On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
>> > > The criteria for using O_NOMTIME is the same as for using O_NOATIME:
>> > > owning the file or having the CAP_FOWNER capability. If we're not
>> > > comfortable allowing owners to prevent mtime/ctime updates then we
>> > > should add a tunable to allow O_NOMTIME. Maybe a mount option?
>> >
>> > I dislike "turn off safety for performance" options because Joe
>> > SpeedRacer will always select performance over safety.
>>
>> Well, for ceph there's no safety concern. They never use cmtime in
>> these files.
>>
>> So are you suggesting not implementing this and making them rework their
>> IO paths to avoid the fs maintaining mtime so that we don't give Joe
>> Speedracer more rope? Or are we talking about adding some speed bumps
>> that ceph can flip on that might give Joe Speedracer pause?
>
> I think this is the fundamental question: who do we give the ammunition
> to, the user or app writer, or the sysadmin?
>
> One might argue that we gave the user a similar power with O_NOATIME (the
> power to break applications that assume atime is accurate). Here we give
> developers/users the power to not update mtime and suffer the consequences
> (like, obviously, breaking mtime-based backups). It should be pretty
> obvious to anyone using the flag what the consequences are.
>
> Note that we can suffer similar lapses in mtime with fdatasync followed by
> a system crash. And as Andy points out it's semi-broken for writable
> mmap. The crash case is obviously a slightly different thing, but the
> idea that mtime can't always be trusted certainly isn't crazy talk.
>
> Or, we can be conservative and require a mount option so that the admin
> has to explicitly allow behavior that might break some existing
> assumptions about mtime/ctime ('-o user_noatime' I guess?).
>
> I'm happy either way, so long as in the end an unprivileged ceph daemon
> avoids the useless work. In our case we always own the entire mount/disk,
> so a mount option is just fine.
>
So, what is the expectation here for filesystems that cannot support
this flag? NFSv3 in particular would break pretty catastrophically if
someone decided on a whim to turn off mtime: they will have turned off
the client's ability to detect cache incoherencies.
Cheers
Trond
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Dave Chinner @ 2015-05-08 2:37 UTC (permalink / raw)
To: Zach Brown
Cc: Alexander Viro, Sage Weil, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150507172053.GA659-fypN+1c5dIyjpB87vu3CluTW4wlIGRCZ@public.gmane.org>
On Thu, May 07, 2015 at 10:20:53AM -0700, Zach Brown wrote:
> On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
> > On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
> > > Add the O_NOMTIME flag which prevents mtime from being updated which can
> > > greatly reduce the IO overhead of writes to allocated and initialized
> > > regions of files.
> >
> > Hmmm. How do backup programs now work out if the file has changed
> > and hence needs copying again? ie. applications using this will
> > break other critical infrastructure in subtle ways.
>
> By using backup infrastructure that doesn't use cmtime. Like btrfs
> send/recv. Or application level backups that know how to do
> incrementals from metadata in giant database files, say, without
> walking, comparing, and copying the entire thing.
"Use magical thing that doesn't exist"? Really?
e.g. you can't do incremental backups with tools like xfsdump if
mtime is not being updated. The last thing an admin wants when
doing disaster recovery is to find out that the app started using
O_NOMTIME as a result of the upgrade they did 6 months ago. Hence
the last 6 months of production data isn't in the backups despite
the backup procedure having been extensively tested and verified
when it was first put in place.
> > > The criteria for using O_NOMTIME is the same as for using O_NOATIME:
> > > owning the file or having the CAP_FOWNER capability. If we're not
> > > comfortable allowing owners to prevent mtime/ctime updates then we
> > > should add a tunable to allow O_NOMTIME. Maybe a mount option?
> >
> > I dislike "turn off safety for performance" options because Joe
> > SpeedRacer will always select performance over safety.
>
> Well, for ceph there's no safety concern. They never use cmtime in
> these files.
Understood.
> So are you suggesting not implementing this
No.
> Or are we talking about adding some speed bumps
> that ceph can flip on that might give Joe Speedracer pause?
Yes, but not just Joe Speedracer - if it can be turned on silently
by apps then it's a great big landmine that most users and sysadmins
will not know about until it is too late.
Cheers,
Dave.
--
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Dave Chinner @ 2015-05-08 2:42 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Richard Weinberger, Zach Brown, Alexander Viro, Sage Weil,
linux-fsdevel, LKML, open list:ABI/API
In-Reply-To: <CALCETrWNDMq0nK3ac-uZweV5BKK_yWTQHH5D0YkyEu7bcONo9g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, May 07, 2015 at 12:53:46PM -0700, Andy Lutomirski wrote:
> On Thu, May 7, 2015 at 12:09 PM, Richard Weinberger
> <richard.weinberger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Thu, May 7, 2015 at 7:20 PM, Zach Brown <zab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >> On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
> >>> On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
> >>> > Add the O_NOMTIME flag which prevents mtime from being updated which can
> >>> > greatly reduce the IO overhead of writes to allocated and initialized
> >>> > regions of files.
> >>>
> >>> Hmmm. How do backup programs now work out if the file has changed
> >>> and hence needs copying again? ie. applications using this will
> >>> break other critical infrastructure in subtle ways.
> >>
> >> By using backup infrastructure that doesn't use cmtime. Like btrfs
> >> send/recv. Or application level backups that know how to do
> >> incrementals from metadata in giant database files, say, without
> >> walking, comparing, and copying the entire thing.
> >
> > But how can Joey random user know that some of his
> > applications are using O_NOMTIME and his KISS backup
> > program does no longer function as expected?
> >
>
> Joey random user can't have a working KISS backup anyway, though,
> because we screw up mtime updates on mmap writes. I have patches
> gathering dust that fix that, though.
They are close enough to be good for backup purposes. The mtime only
need change once per backup period - it doesn't need to be
millisecond accurate. Yes, I know you needed that changed for
different reasons (avoid variable page fault latency), but it
doesn't matter for once-a-day or even once-an-hour incremental
backup scans.
Besides, anyone who cares about accurate backups is doing a backup
from a snapshot so they data and metadata is consistent across the
entire backup. And that makes worries about mmap and mtime
completely irrelevant because a snapshot freezes the filesystem and
hence cleans all the mapped pages. Once the snapshot is taken
the next mmap write will trigger a page fault and so change the
mtime and it will be picked up in the next backup scan...
Cheers,
Dave.
--
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Andy Lutomirski @ 2015-05-08 3:24 UTC (permalink / raw)
To: Dave Chinner
Cc: Al Viro, Sage Weil, Linux API, Linux FS Devel,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Zach Brown
In-Reply-To: <20150508023711.GK4327@dastard>
On May 8, 2015 8:11 AM, "Dave Chinner" <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org> wrote:
>
> On Thu, May 07, 2015 at 10:20:53AM -0700, Zach Brown wrote:
> > On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
> > > On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
> > > > Add the O_NOMTIME flag which prevents mtime from being updated which can
> > > > greatly reduce the IO overhead of writes to allocated and initialized
> > > > regions of files.
> > >
> > > Hmmm. How do backup programs now work out if the file has changed
> > > and hence needs copying again? ie. applications using this will
> > > break other critical infrastructure in subtle ways.
> >
> > By using backup infrastructure that doesn't use cmtime. Like btrfs
> > send/recv. Or application level backups that know how to do
> > incrementals from metadata in giant database files, say, without
> > walking, comparing, and copying the entire thing.
>
> "Use magical thing that doesn't exist"? Really?
>
> e.g. you can't do incremental backups with tools like xfsdump if
> mtime is not being updated. The last thing an admin wants when
> doing disaster recovery is to find out that the app started using
> O_NOMTIME as a result of the upgrade they did 6 months ago. Hence
> the last 6 months of production data isn't in the backups despite
> the backup procedure having been extensively tested and verified
> when it was first put in place.
>
> > > > The criteria for using O_NOMTIME is the same as for using O_NOATIME:
> > > > owning the file or having the CAP_FOWNER capability. If we're not
> > > > comfortable allowing owners to prevent mtime/ctime updates then we
> > > > should add a tunable to allow O_NOMTIME. Maybe a mount option?
> > >
> > > I dislike "turn off safety for performance" options because Joe
> > > SpeedRacer will always select performance over safety.
> >
> > Well, for ceph there's no safety concern. They never use cmtime in
> > these files.
>
> Understood.
>
> > So are you suggesting not implementing this
>
> No.
>
> > Or are we talking about adding some speed bumps
> > that ceph can flip on that might give Joe Speedracer pause?
>
> Yes, but not just Joe Speedracer - if it can be turned on silently
> by apps then it's a great big landmine that most users and sysadmins
> will not know about until it is too late.
What about programs like tar that explicitly override mtime? No admin
buy-in is required for that. Admittedly, that doesn't affect ctime,
nor is it as likely to bite unexpectedly as a nomtime flag.
I think it would be reasonably safe if a mount option had to be set to
allow O_NOCMTIME or such.
--Andy
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 04/10] eeprom: Add a simple EEPROM framework for eeprom consumers
From: Sascha Hauer @ 2015-05-08 5:23 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Stephen Boyd, linux-arm-kernel, Maxime Ripard, Rob Herring,
Kumar Gala, Mark Brown, Greg Kroah-Hartman, linux-api,
linux-kernel, devicetree, linux-arm-msm, arnd
In-Reply-To: <5548AD98.50801@linaro.org>
On Tue, May 05, 2015 at 12:46:32PM +0100, Srinivas Kandagatla wrote:
> Hi Stephen,
>
> Sorry I took so long to reply.
>
>
> On 09/04/15 15:45, Stephen Boyd wrote:
> >On 04/07, Srinivas Kandagatla wrote:
> >>On 07/04/15 19:45, Stephen Boyd wrote:
> >>>On 03/30, Srinivas Kandagatla wrote:
> >>>
> >>>Do you have an overview of how to use these APIs? Maybe some
> >>>Documentation/ is in order? I'm mostly interested in how the
> >>>blocks array is supposed to work and how this hooks up to drivers
> >>>that are using DT.
> >>
> >>Only doc ATM is function level kernel doc in c file.
> >>May be I can explain you for now and I will try to add some
> >>documentation with some usage examples in next version.
> >
> >Thanks.
> >
> >>
> >>eeprom block array is just another way intended to get hold of
> >>eeprom content for non-DT providers/consumers, but DT
> >>consumers/providers can also use it. As of today SOC/mach level code
> >>could use it as well.
> >>
> >>In eeprom_cell_get() case the lookup of provider is done based on
> >>provider name, this provider name is generally supplied by all the
> >>providers (both DT/non DT).
> >>
> >>for example in qfprom case,
> >>provider is registered from DT with eeprom config containing a unique name:
> >>static struct eeprom_config econfig = {
> >> .name = "qfprom",
> >> .id = 0,
> >>};
> >>
> >>In the consumer case, the tsens driver could do some like in non DT way:
> >>
> >> struct eeprom_block blocks[4] ={
> >> {
> >> .offset = 0x404,
> >> .count = 0x4,
> >> },
> >> {
> >> .offset = 0x408,
> >> .count = 0x4,
> >> },
> >> {
> >> .offset = 0x40c,
> >> .count = 0x4,
> >> },
> >> {
> >> .offset = 0x410,
> >> .count = 0x4,
> >> },
> >> };
> >> calib_cell = eeprom_cell_get("qfprom0", blocks, 4);
> >>
> >>
> >>Or in DT way
> >>calib_cell = of_eeprom_cell_get(np, "calib");
> >>
> >
> >Ok. I guess I was hoping for a more device centric approach like
> >we have for clks/regulators/etc. That way a driver doesn't need
> >to know it's using DT or not to figure out which API to call.
>
> That would be the best. Its easy to wrap up whats in eeprom core to
> eeprom_get_cell(dev, "cell-name") for both DT and non-dt cases, if I
> remove the nasty global name space thing.
>
> Only thing which is limiting it is the existing bindings which are
> just phandle based. For eeprom to be more of device centric we need
> more
> generic bindings/property names like
>
> nvrom-cell = <&abc>, <&edf>
> nvrom-cell-names = "cell1", "cell2";
>
> Also we can have name associated to each eeprom cell which would
> help for non-dt cases. So they can just lookup by the cell name.
>
>
> Sacha, Are you ok with such binding? As this can provide a single
> interface for dt and non-dt. I remember you requested for changing
> from generic properties to specific property names.
Yes, I am fine with such a binding. The same type of binding is used for
clocks and other stuff already, so it has proven good and people are
famliar with it.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v3] manpage: update FALLOC_FL_INSERT_RANGE flag in fallocate
From: Namjae Jeon @ 2015-05-08 5:28 UTC (permalink / raw)
To: Michael Kerrisk
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA, Linux API, Dave Chinner,
Theodore Ts'o
Update FALLOC_FL_INSERT_RANGE flag in fallocate.
Signed-off-by: Namjae Jeon <namjae.jeon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Ashish Sangwan <a.sangwan-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
man2/fallocate.2 | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 84 insertions(+), 5 deletions(-)
diff --git a/man2/fallocate.2 b/man2/fallocate.2
index 0cc1a00..0d31027 100644
--- a/man2/fallocate.2
+++ b/man2/fallocate.2
@@ -228,6 +228,59 @@ ext4, for extent-based files (since Linux 3.15)
.IP *
SMB3 (since Linux 3.17)
.\" commit 30175628bf7f521e9ee31ac98fa6d6fe7441a556
+.SS Increasing file space
+flag (available since Linux 4.1)
+.\" commit dd46c787788d5bf5b974729d43e4c405814a4c7d
+Specifying the
+.BR FALLOC_FL_INSERT_RANGE
+flag in
+.I mode
+will increase the file space by inserting a hole within the file size without
+overwriting any existing data.
+The hole will start at
+.I offset
+and continue for
+.I len
+bytes.
+For inserting hole inside file, the contents of the file starting at
+.I offset
+will be shifted towards right by
+.I len
+bytes.
+Inserting a hole inside the file will increase the file size by
+.I len
+bytes.
+
+This mode has the same limitation as
+.BR FALLOC_FL_COLLAPSE_RANGE
+regarding the
+granularity of the operation.
+If the granularity requirements are not met,
+.BR fallocate ()
+will fail with the error
+.BR EINVAL.
+If the
+.I offset
+is greater than or equal to the end of file, an error is
+returned.
+For such type of operations, i.e. inserting a hole at the end of file,
+.BR ftruncate(2)
+should be used.
+In case
+.IR offset + len
+exceeds the maximum file size, errno will be set to
+.B EFBIG.
+
+No other flags may be specified in
+.IR mode
+in conjunction with
+.BR FALLOC_FL_INSERT_RANGE .
+
+As of Linux 4.1,
+.B FALLOC_FL_INSERT_RANGE
+is supported by
+XFS.
+.\" commit a904b1ca5751faf5ece8600e18cd3b674afcca1b
.SH RETURN VALUE
On success,
.BR fallocate ()
@@ -245,6 +298,12 @@ is not a valid file descriptor, or is not opened for writing.
.IR offset + len
exceeds the maximum file size.
.TP
+.B EFBIG
+.I mode
+is
+.BR FALLOC_FL_INSERT_RANGE ,
+the current file size+len exceeds the maximum file size.
+.TP
.B EINTR
A signal was caught during execution.
.TP
@@ -273,7 +332,17 @@ reaches or passes the end of the file.
.B EINVAL
.I mode
is
-.BR FALLOC_FL_COLLAPSE_RANGE ,
+.BR FALLOC_FL_INSERT_RANGE
+and the range specified by
+.I offset
+reaches or passes the end of the file.
+.TP
+.B EINVAL
+.I mode
+is
+.BR FALLOC_FL_COLLAPSE_RANGE
+or
+.BR FALLOC_FL_INSERT_RANGE ,
but either
.I offset
or
@@ -282,18 +351,24 @@ is not a multiple of the filesystem block size.
.TP
.B EINVAL
.I mode
-contains both
+contains either of
.B FALLOC_FL_COLLAPSE_RANGE
+or
+.B FALLOC_FL_INSERT_RANGE
and other flags;
no other flags are permitted with
-.BR FALLOC_FL_COLLAPSE_RANGE .
+.BR FALLOC_FL_COLLAPSE_RANGE
+or
+.BR FALLOC_FL_INSERT_RANGE .
.TP
.B EINVAL
.I mode
is
.BR FALLOC_FL_COLLAPSE_RANGE
or
-.BR FALLOC_FL_ZERO_RANGE ,
+.BR FALLOC_FL_ZERO_RANGE
+or
+.BR FALLOC_FL_INSERT_RANGE ,
but the file referred to by
.I fd
is not a regular file.
@@ -345,6 +420,8 @@ specifies
.BR FALLOC_FL_PUNCH_HOLE
or
.BR FALLOC_FL_COLLAPSE_RANGE
+or
+.BR FALLOC_FL_INSERT_RANGE
and
the file referred to by
.I fd
@@ -363,7 +440,9 @@ refers to a pipe or FIFO.
.B ETXTBSY
.I mode
specifies
-.BR FALLOC_FL_COLLAPSE_RANGE ,
+.BR FALLOC_FL_COLLAPSE_RANGE
+or
+.BR FALLOC_FL_INSERT_RANGE ,
but the file referred to by
.IR fd
is currently being executed.
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 01/11] coresight-etm4x: Adding CoreSight ETM4x driver
From: Ivan T. Ivanov @ 2015-05-08 8:27 UTC (permalink / raw)
To: Mathieu Poirier
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kaixu.xia-QSEj5FYQhm4dnm+yROfE0A,
zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1430926047-9125-2-git-send-email-mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Mathieu,
On Wed, 2015-05-06 at 09:27 -0600, Mathieu Poirier wrote:
>
> +static struct amba_id etm4_ids[] = {
> + { /* ETM 4.0 - Juno board */
> + .id = 0x000bb95e,
> + .mask = 0x000fffff,
> + .data = "ETM 4.0",
> + },
> + { 0, 0},
> +};
> +
>
Any particular reason to remove device ID for the
Hi6220 board? It happens to be the same ID used in
Qualcomm 8x16 ETM components.
Regards,
Ivan
^ permalink raw reply
* Re: [PATCH v3 01/12] KVM: add comments for kvm_debug_exit_arch struct
From: Christoffer Dall @ 2015-05-08 9:19 UTC (permalink / raw)
To: Alex Bennée
Cc: kvm, linux-arm-kernel, kvmarm, marc.zyngier, peter.maydell, agraf,
drjones, pbonzini, zhichao.huang, jan.kiszka, dahi, r65777, bp,
Gleb Natapov, Jonathan Corbet, open list:DOCUMENTATION, open list,
open list:ABI/API
In-Reply-To: <1430929407-3487-2-git-send-email-alex.bennee@linaro.org>
On Wed, May 06, 2015 at 05:23:16PM +0100, Alex Bennée wrote:
> Bring into line with the comments for the other structures and their
> KVM_EXIT_* cases. Also update api.txt to reflect use in kvm_run
> documentation.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
> Reviewed-by: Andrew Jones <drjones@redhat.com>
>
> ---
>
> v2
> - add comments for other exit types
> v3
> - s/commentary/comments/
> - add rb tags
> - update api.txt kvm_run to include KVM_EXIT_DEBUG desc
>
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 9fa2bf8..cb90025 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -3070,11 +3070,13 @@ data_offset describes where the data is located (KVM_EXIT_IO_OUT) or
> where kvm expects application code to place the data for the next
> KVM_RUN invocation (KVM_EXIT_IO_IN). Data format is a packed array.
>
> + /* KVM_EXIT_DEBUG */
> struct {
> struct kvm_debug_exit_arch arch;
> } debug;
>
> -Unused.
> +If the exit_reason in KVM_EXIT_DEBUG, then a vcpu is processing a debug event
s/in/is/
> +for which architecture dependant information is returned.
s/dependant/dependent/ (but maybe architecture specific is better)
>
> /* KVM_EXIT_MMIO */
> struct {
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 4b60056..70ac641 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -237,6 +237,7 @@ struct kvm_run {
> __u32 count;
> __u64 data_offset; /* relative to kvm_run start */
> } io;
> + /* KVM_EXIT_DEBUG */
> struct {
> struct kvm_debug_exit_arch arch;
> } debug;
> @@ -285,6 +286,7 @@ struct kvm_run {
> __u32 data;
> __u8 is_write;
> } dcr;
> + /* KVM_EXIT_INTERNAL_ERROR */
> struct {
> __u32 suberror;
> /* Available with KVM_CAP_INTERNAL_ERROR_DATA: */
> @@ -295,6 +297,7 @@ struct kvm_run {
> struct {
> __u64 gprs[32];
> } osi;
> + /* KVM_EXIT_PAPR_HCALL */
> struct {
> __u64 nr;
> __u64 ret;
> --
> 2.3.5
>
otherwise:
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
^ permalink raw reply
* Re: [PATCH v3 02/12] KVM: define common __KVM_GUESTDBG_USE_SW/HW_BP values
From: Christoffer Dall @ 2015-05-08 9:23 UTC (permalink / raw)
To: Alex Bennée
Cc: kvm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, marc.zyngier-5wv7dgnIgG8,
peter.maydell-QSEj5FYQhm4dnm+yROfE0A, agraf-l3A5Bk7waGM,
drjones-H+wXaHxf7aLQT0dZR+AlfA, pbonzini-H+wXaHxf7aLQT0dZR+AlfA,
zhichao.huang-QSEj5FYQhm4dnm+yROfE0A,
jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ,
dahi-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
r65777-KZfg59tc24xl57MIdRCFDg, bp-l3A5Bk7waGM,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE..., Gleb Natapov, Bharat Bhushan,
Mihai Caraman, Alexey Kardashevskiy, Nadav Amit,
open list:LINUX FOR POWERPC..., open list
In-Reply-To: <1430929407-3487-3-git-send-email-alex.bennee-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Wed, May 06, 2015 at 05:23:17PM +0100, Alex Bennée wrote:
> Currently x86, powerpc and soon arm64 use the same two architecture
> specific bits for guest debug support for software and hardware
> breakpoints. This makes the shared values explicit while leaving the
> gate open for another architecture to use some other value if they
> really really want to.
>
> Signed-off-by: Alex Bennée <alex.bennee-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Reviewed-by: Andrew Jones <drjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index ab4d473..1731569 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -310,8 +310,8 @@ struct kvm_guest_debug_arch {
> * and upper 16 bits are architecture specific. Architecture specific defines
> * that ioctl is for setting hardware breakpoint or software breakpoint.
> */
> -#define KVM_GUESTDBG_USE_SW_BP 0x00010000
> -#define KVM_GUESTDBG_USE_HW_BP 0x00020000
> +#define KVM_GUESTDBG_USE_SW_BP __KVM_GUESTDBG_USE_SW_BP
> +#define KVM_GUESTDBG_USE_HW_BP __KVM_GUESTDBG_USE_HW_BP
>
> /* definition of registers in kvm_run */
> struct kvm_sync_regs {
> diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
> index d7dcef5..1438202 100644
> --- a/arch/x86/include/uapi/asm/kvm.h
> +++ b/arch/x86/include/uapi/asm/kvm.h
> @@ -250,8 +250,8 @@ struct kvm_debug_exit_arch {
> __u64 dr7;
> };
>
> -#define KVM_GUESTDBG_USE_SW_BP 0x00010000
> -#define KVM_GUESTDBG_USE_HW_BP 0x00020000
> +#define KVM_GUESTDBG_USE_SW_BP __KVM_GUESTDBG_USE_SW_BP
> +#define KVM_GUESTDBG_USE_HW_BP __KVM_GUESTDBG_USE_HW_BP
> #define KVM_GUESTDBG_INJECT_DB 0x00040000
> #define KVM_GUESTDBG_INJECT_BP 0x00080000
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 70ac641..3b6252e 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -570,8 +570,16 @@ struct kvm_s390_irq_state {
>
> /* for KVM_SET_GUEST_DEBUG */
>
> -#define KVM_GUESTDBG_ENABLE 0x00000001
> -#define KVM_GUESTDBG_SINGLESTEP 0x00000002
> +#define KVM_GUESTDBG_ENABLE (1 << 0)
> +#define KVM_GUESTDBG_SINGLESTEP (1 << 1)
> +
> +/*
> + * Architecture specific stuff uses the top 16 bits of the field,
s/stuff/<something more specific>/
> + * however there is some shared commonality for the common cases
> + */
> +#define __KVM_GUESTDBG_USE_SW_BP (1 << 16)
> +#define __KVM_GUESTDBG_USE_HW_BP (1 << 17)
> +
>
> struct kvm_guest_debug {
> __u32 control;
We sort of left this discussion hanging with me expressing slight
concern about the usefulness about these defines.
Paolo, what are your thoughts?
-Christoffer
^ permalink raw reply
* Re: [PATCH v3] manpage: update FALLOC_FL_INSERT_RANGE flag in fallocate
From: Michael Kerrisk (man-pages) @ 2015-05-08 9:40 UTC (permalink / raw)
To: Namjae Jeon
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA, Linux API, Dave Chinner,
Theodore Ts'o
In-Reply-To: <009201d0894f$d87f0890$897d19b0$@samsung.com>
Hi Namjae,
> Update FALLOC_FL_INSERT_RANGE flag in fallocate.
Sorry -- I should have said that I already applied your V2
patch and made the fix we discussed (and that you add below).
I just hadn't pushed to Git yet. Done now.
Cheers,
Michael
On 05/08/2015 07:28 AM, Namjae Jeon wrote:
> Signed-off-by: Namjae Jeon <namjae.jeon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Ashish Sangwan <a.sangwan-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> man2/fallocate.2 | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 84 insertions(+), 5 deletions(-)
>
> diff --git a/man2/fallocate.2 b/man2/fallocate.2
> index 0cc1a00..0d31027 100644
> --- a/man2/fallocate.2
> +++ b/man2/fallocate.2
> @@ -228,6 +228,59 @@ ext4, for extent-based files (since Linux 3.15)
> .IP *
> SMB3 (since Linux 3.17)
> .\" commit 30175628bf7f521e9ee31ac98fa6d6fe7441a556
> +.SS Increasing file space
> +flag (available since Linux 4.1)
> +.\" commit dd46c787788d5bf5b974729d43e4c405814a4c7d
> +Specifying the
> +.BR FALLOC_FL_INSERT_RANGE
> +flag in
> +.I mode
> +will increase the file space by inserting a hole within the file size without
> +overwriting any existing data.
> +The hole will start at
> +.I offset
> +and continue for
> +.I len
> +bytes.
> +For inserting hole inside file, the contents of the file starting at
> +.I offset
> +will be shifted towards right by
> +.I len
> +bytes.
> +Inserting a hole inside the file will increase the file size by
> +.I len
> +bytes.
> +
> +This mode has the same limitation as
> +.BR FALLOC_FL_COLLAPSE_RANGE
> +regarding the
> +granularity of the operation.
> +If the granularity requirements are not met,
> +.BR fallocate ()
> +will fail with the error
> +.BR EINVAL.
> +If the
> +.I offset
> +is greater than or equal to the end of file, an error is
> +returned.
> +For such type of operations, i.e. inserting a hole at the end of file,
> +.BR ftruncate(2)
> +should be used.
> +In case
> +.IR offset + len
> +exceeds the maximum file size, errno will be set to
> +.B EFBIG.
> +
> +No other flags may be specified in
> +.IR mode
> +in conjunction with
> +.BR FALLOC_FL_INSERT_RANGE .
> +
> +As of Linux 4.1,
> +.B FALLOC_FL_INSERT_RANGE
> +is supported by
> +XFS.
> +.\" commit a904b1ca5751faf5ece8600e18cd3b674afcca1b
> .SH RETURN VALUE
> On success,
> .BR fallocate ()
> @@ -245,6 +298,12 @@ is not a valid file descriptor, or is not opened for writing.
> .IR offset + len
> exceeds the maximum file size.
> .TP
> +.B EFBIG
> +.I mode
> +is
> +.BR FALLOC_FL_INSERT_RANGE ,
> +the current file size+len exceeds the maximum file size.
> +.TP
> .B EINTR
> A signal was caught during execution.
> .TP
> @@ -273,7 +332,17 @@ reaches or passes the end of the file.
> .B EINVAL
> .I mode
> is
> -.BR FALLOC_FL_COLLAPSE_RANGE ,
> +.BR FALLOC_FL_INSERT_RANGE
> +and the range specified by
> +.I offset
> +reaches or passes the end of the file.
> +.TP
> +.B EINVAL
> +.I mode
> +is
> +.BR FALLOC_FL_COLLAPSE_RANGE
> +or
> +.BR FALLOC_FL_INSERT_RANGE ,
> but either
> .I offset
> or
> @@ -282,18 +351,24 @@ is not a multiple of the filesystem block size.
> .TP
> .B EINVAL
> .I mode
> -contains both
> +contains either of
> .B FALLOC_FL_COLLAPSE_RANGE
> +or
> +.B FALLOC_FL_INSERT_RANGE
> and other flags;
> no other flags are permitted with
> -.BR FALLOC_FL_COLLAPSE_RANGE .
> +.BR FALLOC_FL_COLLAPSE_RANGE
> +or
> +.BR FALLOC_FL_INSERT_RANGE .
> .TP
> .B EINVAL
> .I mode
> is
> .BR FALLOC_FL_COLLAPSE_RANGE
> or
> -.BR FALLOC_FL_ZERO_RANGE ,
> +.BR FALLOC_FL_ZERO_RANGE
> +or
> +.BR FALLOC_FL_INSERT_RANGE ,
> but the file referred to by
> .I fd
> is not a regular file.
> @@ -345,6 +420,8 @@ specifies
> .BR FALLOC_FL_PUNCH_HOLE
> or
> .BR FALLOC_FL_COLLAPSE_RANGE
> +or
> +.BR FALLOC_FL_INSERT_RANGE
> and
> the file referred to by
> .I fd
> @@ -363,7 +440,9 @@ refers to a pipe or FIFO.
> .B ETXTBSY
> .I mode
> specifies
> -.BR FALLOC_FL_COLLAPSE_RANGE ,
> +.BR FALLOC_FL_COLLAPSE_RANGE
> +or
> +.BR FALLOC_FL_INSERT_RANGE ,
> but the file referred to by
> .IR fd
> is currently being executed.
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox