Re: [fuse-devel] [PATCH 0/8] MUSE: Userspace backed MTD v3

[Luca Risolia]

On 09/02/21 17:50, Richard Weinberger wrote:

Well, I think having a generic mmap() for CUSE is hard to achieve.


Hard or not it did work for what I can tell you. I was not the original 
author but I certainly contributed with testing that patch. Just to be 
clear, by "not considered" I meant both the patch and the request were 
completely ignored with no answers at all, silence in other words.

Re: [fuse-devel] [PATCH 0/8] MUSE: Userspace backed MTD v3

[Luca Risolia]

On 09/02/21 17:29, Richard Weinberger wrote:

The mmap() call itself. Of course you need to touch code.
Maybe just cuse_lowlevel.c, maybe kernel too.


A patch had been submitted some years ago, more than once, asking for 
inclusion in the kernel, but facts are that at that time nobody in the 
FUSE group considered it. So much work and time lost, unfortunately.

Re: [fuse-devel] [PATCH 0/8] MUSE: Userspace backed MTD v3

[Luca Risolia]

A simple (but ugly!) approach would be redirecting mmap() requests on CUSE 
devices to /dev/mem.
hmm?


what requests are you talking about given that at the moment the CUSE 
client interface (cuse_lowlevel_ops) does not expose mmap?

Re: [fuse-devel] [PATCH 0/8] MUSE: Userspace backed MTD v3

[Luca Risolia]

On 09/02/21 16:41, Richard Weinberger wrote:

I wonder about the use case.


for example, many existing video applications use mmap() to map the 
device memory to userspace memory. Adding support for mmap() to CUSE 
would allow these apps to work without any modifications with CUSE-based 
 device drivers other than kernel drivers.

Re: [fuse-devel] [PATCH 0/8] MUSE: Userspace backed MTD v3

[Luca Risolia]

Hi guys,

a bit OT probably: is there any chance for you to also implement mmap() 
for CUSE? That would be much appreciated.


Thanks


On 09/02/21 15:35, Richard Weinberger wrote:

Miklos,

- Ursprüngliche Mail -

The core goal of MUSE is having the complexity on the userspace side and
only a small MTD driver in kernelspace.
While playing with different approaches I realized that FUSE offers everything
we need. So MUSE is a little like CUSE except that it does not implement a
bare character device but an MTD.


Looks fine.


I'm glad to hear that!


I do wonder if MUSE should go to drivers/mtd/ instead.   Long term
goal would be move CUSE to drivers/char and move the transport part of
fuse into net/fuse leaving only the actual filesystems (fuse and
virtiofs) under fs/.

But for now just moving the minimal interface needed for MUSE into a
separate header () would work, I guess.

Do you think that would make sense?


Yes, I'm all for having MUSE in drivers/mtd/.

I placed MUSE initially in fs/fuse/ because CUSE was already there and muse.c 
includes
fuse_i.h. So tried to be as little invasive as possible.



Notes:
--

- OOB support is currently limited. Currently MUSE has no support for processing
   in- and out-band in the same MTD operation. It is good enough to make JFFS2
   happy. This limitation is because FUSE has no support more than one variable
   length buffer in a FUSE request.
   At least I didn’t find a good way to pass more than one buffer to a request.
   Maybe FUSE folks can correct me. :-)


If you look at fuse_do_ioctl() it does variable length input and
output at the same time.  I guess you need something similar to that.


I'll dig into this!

Thanks,
//richard

Re: [PATCH] fuse: implement cuse mmap

[Luca Risolia]

Hi Andrew,

I was wondering if there's a chance to have this patch merged anytime 
soon. Note that FUSE maintainer left off sometime ago and there's no one 
taking care of kernel patches at the moment.


Please let Jader and me know if there are any problems.

Thanks

Jader H. Silva wrote:

Implement cuse mmap using shmem to provide the actual memory maps.
Pages must be read/written using fuse's NOTIFY_RETRIEVE and NOTIFY_STORE api.

Signed-off-by: Jader H. Silva 
---
  fs/fuse/cuse.c| 459 +-
  fs/fuse/dev.c | 163 +---
  fs/fuse/fuse_i.h  |  34 +++-
  fs/fuse/inode.c   | 166 -
  include/uapi/linux/fuse.h |  26 +++
  5 files changed, 688 insertions(+), 160 deletions(-)

diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c
index eae2c11..7749c13 100644
--- a/fs/fuse/cuse.c
+++ b/fs/fuse/cuse.c
@@ -48,6 +48,9 @@
  #include 
  #include 
  #include 
+#include 
+#include 
+#include 

  #include "fuse_i.h"

@@ -175,6 +178,441 @@ static long cuse_file_compat_ioctl(struct file *file, 
unsigned int cmd,
return fuse_do_ioctl(file, cmd, arg, flags);
  }

+struct fuse_dmmap_region {
+   u64 mapid;
+   u64 size;
+   struct file *filp;
+   struct vm_operations_struct vm_ops;
+   const struct vm_operations_struct *vm_original_ops;
+   struct list_head list;
+   atomic_t ref;
+};
+
+/*
+ * fuse_dmmap_vm represents the result of a single mmap() call, which
+ * can be shared by multiple client vmas created by forking.
+ */
+struct fuse_dmmap_vm {
+   u64 len;
+   u64 off;
+   atomic_t open_count;
+   struct fuse_dmmap_region *region;
+};
+
+static void fuse_dmmap_region_put(struct fuse_conn *fc,
+ struct fuse_dmmap_region *fdr)
+{
+   if (atomic_dec_and_lock(>ref, >lock)) {
+
+   list_del(>list);
+
+   spin_unlock(>lock);
+
+   fput(fdr->filp);
+   kfree(fdr);
+   }
+}
+
+static void fuse_dmmap_vm_open(struct vm_area_struct *vma)
+{
+   struct fuse_dmmap_vm *fdvm = vma->vm_private_data;
+   struct fuse_dmmap_region *fdr = fdvm->region;
+
+   /* vma copied */
+   atomic_inc(>open_count);
+
+   if (fdr->vm_original_ops->open)
+   fdr->vm_original_ops->open(vma);
+}
+
+static void fuse_dmmap_vm_close(struct vm_area_struct *vma)
+{
+   struct fuse_dmmap_vm *fdvm = vma->vm_private_data;
+   struct fuse_dmmap_region *fdr = fdvm->region;
+   struct fuse_file *ff = vma->vm_file->private_data;
+   struct fuse_conn *fc = ff->fc;
+   struct fuse_req *req;
+   struct fuse_munmap_in *inarg;
+
+   if (fdr->vm_original_ops->close)
+   fdr->vm_original_ops->close(vma);
+
+   if (!atomic_dec_and_test(>open_count))
+   return;
+
+   /*
+* Notify server that the mmap region has been unmapped.
+* Failing this might lead to resource leak in server, don't
+* fail.
+*/
+   req = fuse_get_req_nofail_nopages(fc, vma->vm_file);
+   inarg = >misc.munmap_in;
+
+   inarg->fh = ff->fh;
+   inarg->mapid = fdvm->region->mapid;
+   inarg->size = fdvm->len;
+   inarg->offset = fdvm->off;
+
+   req->in.h.opcode = FUSE_MUNMAP;
+   req->in.h.nodeid = ff->nodeid;
+   req->in.numargs = 1;
+   req->in.args[0].size = sizeof(*inarg);
+   req->in.args[0].value = inarg;
+
+   fuse_request_send(fc, req);
+   fuse_put_request(fc, req);
+   fuse_dmmap_region_put(fc, fdvm->region);
+   kfree(fdvm);
+}
+
+static int fuse_dmmap_vm_fault(struct vm_area_struct *vma, struct vm_fault 
*vmf)
+{
+   int ret;
+   struct file *filp = vma->vm_file;
+   struct fuse_dmmap_vm *fdvm = vma->vm_private_data;
+   struct fuse_dmmap_region *fdr = fdvm->region;
+
+   vma->vm_file = fdr->filp;
+   ret = fdr->vm_original_ops->fault(vma, vmf);
+
+   vma->vm_file = filp;
+
+   return ret;
+}
+
+static const struct vm_operations_struct fuse_dmmap_vm_ops = {
+   .open   = fuse_dmmap_vm_open,
+   .close  = fuse_dmmap_vm_close,
+   .fault  = fuse_dmmap_vm_fault,
+};
+
+static struct fuse_dmmap_region *fuse_dmmap_find_locked(struct fuse_conn *fc,
+   u64 mapid)
+{
+   struct fuse_dmmap_region *curr;
+   struct fuse_dmmap_region *fdr = NULL;
+
+   list_for_each_entry(curr, >dmmap_list, list) {
+   if (curr->mapid == mapid) {
+   fdr = curr;
+   atomic_inc(>ref);
+   break;
+   }
+   }
+
+   return fdr;
+}
+
+static struct fuse_dmmap_region *fuse_dmmap_find(struct fuse_conn *fc,
+u64 mapid)
+{
+   struct fuse_dmmap_region *fdr;
+
+   spin_lock(>lock);
+   fdr = fuse_dmmap_find_locked(fc, mapid);
+   

Re: [PATCH] fuse: implement cuse mmap

[Luca Risolia]

Hi Andrew,

I was wondering if there's a chance to have this patch merged anytime 
soon. Note that FUSE maintainer left off sometime ago and there's no one 
taking care of kernel patches at the moment.


Please let Jader and me know if there are any problems.

Thanks

Jader H. Silva wrote:

Implement cuse mmap using shmem to provide the actual memory maps.
Pages must be read/written using fuse's NOTIFY_RETRIEVE and NOTIFY_STORE api.

Signed-off-by: Jader H. Silva 
---
  fs/fuse/cuse.c| 459 +-
  fs/fuse/dev.c | 163 +---
  fs/fuse/fuse_i.h  |  34 +++-
  fs/fuse/inode.c   | 166 -
  include/uapi/linux/fuse.h |  26 +++
  5 files changed, 688 insertions(+), 160 deletions(-)

diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c
index eae2c11..7749c13 100644
--- a/fs/fuse/cuse.c
+++ b/fs/fuse/cuse.c
@@ -48,6 +48,9 @@
  #include 
  #include 
  #include 
+#include 
+#include 
+#include 

  #include "fuse_i.h"

@@ -175,6 +178,441 @@ static long cuse_file_compat_ioctl(struct file *file, 
unsigned int cmd,
return fuse_do_ioctl(file, cmd, arg, flags);
  }

+struct fuse_dmmap_region {
+   u64 mapid;
+   u64 size;
+   struct file *filp;
+   struct vm_operations_struct vm_ops;
+   const struct vm_operations_struct *vm_original_ops;
+   struct list_head list;
+   atomic_t ref;
+};
+
+/*
+ * fuse_dmmap_vm represents the result of a single mmap() call, which
+ * can be shared by multiple client vmas created by forking.
+ */
+struct fuse_dmmap_vm {
+   u64 len;
+   u64 off;
+   atomic_t open_count;
+   struct fuse_dmmap_region *region;
+};
+
+static void fuse_dmmap_region_put(struct fuse_conn *fc,
+ struct fuse_dmmap_region *fdr)
+{
+   if (atomic_dec_and_lock(>ref, >lock)) {
+
+   list_del(>list);
+
+   spin_unlock(>lock);
+
+   fput(fdr->filp);
+   kfree(fdr);
+   }
+}
+
+static void fuse_dmmap_vm_open(struct vm_area_struct *vma)
+{
+   struct fuse_dmmap_vm *fdvm = vma->vm_private_data;
+   struct fuse_dmmap_region *fdr = fdvm->region;
+
+   /* vma copied */
+   atomic_inc(>open_count);
+
+   if (fdr->vm_original_ops->open)
+   fdr->vm_original_ops->open(vma);
+}
+
+static void fuse_dmmap_vm_close(struct vm_area_struct *vma)
+{
+   struct fuse_dmmap_vm *fdvm = vma->vm_private_data;
+   struct fuse_dmmap_region *fdr = fdvm->region;
+   struct fuse_file *ff = vma->vm_file->private_data;
+   struct fuse_conn *fc = ff->fc;
+   struct fuse_req *req;
+   struct fuse_munmap_in *inarg;
+
+   if (fdr->vm_original_ops->close)
+   fdr->vm_original_ops->close(vma);
+
+   if (!atomic_dec_and_test(>open_count))
+   return;
+
+   /*
+* Notify server that the mmap region has been unmapped.
+* Failing this might lead to resource leak in server, don't
+* fail.
+*/
+   req = fuse_get_req_nofail_nopages(fc, vma->vm_file);
+   inarg = >misc.munmap_in;
+
+   inarg->fh = ff->fh;
+   inarg->mapid = fdvm->region->mapid;
+   inarg->size = fdvm->len;
+   inarg->offset = fdvm->off;
+
+   req->in.h.opcode = FUSE_MUNMAP;
+   req->in.h.nodeid = ff->nodeid;
+   req->in.numargs = 1;
+   req->in.args[0].size = sizeof(*inarg);
+   req->in.args[0].value = inarg;
+
+   fuse_request_send(fc, req);
+   fuse_put_request(fc, req);
+   fuse_dmmap_region_put(fc, fdvm->region);
+   kfree(fdvm);
+}
+
+static int fuse_dmmap_vm_fault(struct vm_area_struct *vma, struct vm_fault 
*vmf)
+{
+   int ret;
+   struct file *filp = vma->vm_file;
+   struct fuse_dmmap_vm *fdvm = vma->vm_private_data;
+   struct fuse_dmmap_region *fdr = fdvm->region;
+
+   vma->vm_file = fdr->filp;
+   ret = fdr->vm_original_ops->fault(vma, vmf);
+
+   vma->vm_file = filp;
+
+   return ret;
+}
+
+static const struct vm_operations_struct fuse_dmmap_vm_ops = {
+   .open   = fuse_dmmap_vm_open,
+   .close  = fuse_dmmap_vm_close,
+   .fault  = fuse_dmmap_vm_fault,
+};
+
+static struct fuse_dmmap_region *fuse_dmmap_find_locked(struct fuse_conn *fc,
+   u64 mapid)
+{
+   struct fuse_dmmap_region *curr;
+   struct fuse_dmmap_region *fdr = NULL;
+
+   list_for_each_entry(curr, >dmmap_list, list) {
+   if (curr->mapid == mapid) {
+   fdr = curr;
+   atomic_inc(>ref);
+   break;
+   }
+   }
+
+   return fdr;
+}
+
+static struct fuse_dmmap_region *fuse_dmmap_find(struct fuse_conn *fc,
+u64 mapid)
+{
+   struct fuse_dmmap_region *fdr;
+
+   spin_lock(>lock);
+   fdr = 

Re: [PATCH] fuse: implement cuse mmap

[Luca Risolia]

I tested this patch and gave some hints to Jader when it first appeared 
on the libfuse mailing list some months ago.


Signed-off-by: Luca Risolia 

Jader H. Silva wrote:

Implement cuse mmap using shmem to provide the actual memory maps.
Pages must be read/written using fuse's NOTIFY_RETRIEVE and NOTIFY_STORE api.

Signed-off-by: Jader H. Silva 
---
  fs/fuse/cuse.c| 459 +-
  fs/fuse/dev.c | 163 +---
  fs/fuse/fuse_i.h  |  34 +++-
  fs/fuse/inode.c   | 166 -
  include/uapi/linux/fuse.h |  26 +++
  5 files changed, 688 insertions(+), 160 deletions(-)

diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c
index eae2c11..7749c13 100644
--- a/fs/fuse/cuse.c
+++ b/fs/fuse/cuse.c
@@ -48,6 +48,9 @@
  #include 
  #include 
  #include 
+#include 
+#include 
+#include 

  #include "fuse_i.h"

@@ -175,6 +178,441 @@ static long cuse_file_compat_ioctl(struct file *file, 
unsigned int cmd,
return fuse_do_ioctl(file, cmd, arg, flags);
  }

+struct fuse_dmmap_region {
+   u64 mapid;
+   u64 size;
+   struct file *filp;
+   struct vm_operations_struct vm_ops;
+   const struct vm_operations_struct *vm_original_ops;
+   struct list_head list;
+   atomic_t ref;
+};
+
+/*
+ * fuse_dmmap_vm represents the result of a single mmap() call, which
+ * can be shared by multiple client vmas created by forking.
+ */
+struct fuse_dmmap_vm {
+   u64 len;
+   u64 off;
+   atomic_t open_count;
+   struct fuse_dmmap_region *region;
+};
+
+static void fuse_dmmap_region_put(struct fuse_conn *fc,
+ struct fuse_dmmap_region *fdr)
+{
+   if (atomic_dec_and_lock(>ref, >lock)) {
+
+   list_del(>list);
+
+   spin_unlock(>lock);
+
+   fput(fdr->filp);
+   kfree(fdr);
+   }
+}
+
+static void fuse_dmmap_vm_open(struct vm_area_struct *vma)
+{
+   struct fuse_dmmap_vm *fdvm = vma->vm_private_data;
+   struct fuse_dmmap_region *fdr = fdvm->region;
+
+   /* vma copied */
+   atomic_inc(>open_count);
+
+   if (fdr->vm_original_ops->open)
+   fdr->vm_original_ops->open(vma);
+}
+
+static void fuse_dmmap_vm_close(struct vm_area_struct *vma)
+{
+   struct fuse_dmmap_vm *fdvm = vma->vm_private_data;
+   struct fuse_dmmap_region *fdr = fdvm->region;
+   struct fuse_file *ff = vma->vm_file->private_data;
+   struct fuse_conn *fc = ff->fc;
+   struct fuse_req *req;
+   struct fuse_munmap_in *inarg;
+
+   if (fdr->vm_original_ops->close)
+   fdr->vm_original_ops->close(vma);
+
+   if (!atomic_dec_and_test(>open_count))
+   return;
+
+   /*
+* Notify server that the mmap region has been unmapped.
+* Failing this might lead to resource leak in server, don't
+* fail.
+*/
+   req = fuse_get_req_nofail_nopages(fc, vma->vm_file);
+   inarg = >misc.munmap_in;
+
+   inarg->fh = ff->fh;
+   inarg->mapid = fdvm->region->mapid;
+   inarg->size = fdvm->len;
+   inarg->offset = fdvm->off;
+
+   req->in.h.opcode = FUSE_MUNMAP;
+   req->in.h.nodeid = ff->nodeid;
+   req->in.numargs = 1;
+   req->in.args[0].size = sizeof(*inarg);
+   req->in.args[0].value = inarg;
+
+   fuse_request_send(fc, req);
+   fuse_put_request(fc, req);
+   fuse_dmmap_region_put(fc, fdvm->region);
+   kfree(fdvm);
+}
+
+static int fuse_dmmap_vm_fault(struct vm_area_struct *vma, struct vm_fault 
*vmf)
+{
+   int ret;
+   struct file *filp = vma->vm_file;
+   struct fuse_dmmap_vm *fdvm = vma->vm_private_data;
+   struct fuse_dmmap_region *fdr = fdvm->region;
+
+   vma->vm_file = fdr->filp;
+   ret = fdr->vm_original_ops->fault(vma, vmf);
+
+   vma->vm_file = filp;
+
+   return ret;
+}
+
+static const struct vm_operations_struct fuse_dmmap_vm_ops = {
+   .open   = fuse_dmmap_vm_open,
+   .close  = fuse_dmmap_vm_close,
+   .fault  = fuse_dmmap_vm_fault,
+};
+
+static struct fuse_dmmap_region *fuse_dmmap_find_locked(struct fuse_conn *fc,
+   u64 mapid)
+{
+   struct fuse_dmmap_region *curr;
+   struct fuse_dmmap_region *fdr = NULL;
+
+   list_for_each_entry(curr, >dmmap_list, list) {
+   if (curr->mapid == mapid) {
+   fdr = curr;
+   atomic_inc(>ref);
+   break;
+   }
+   }
+
+   return fdr;
+}
+
+static struct fuse_dmmap_region *fuse_dmmap_find(struct fuse_conn *fc,
+u64 mapid)
+{
+   struct fuse_dmmap_region *fdr;
+
+   spin_lock(>lock);
+  

Re: [PATCH] fuse: implement cuse mmap

[Luca Risolia]

I tested this patch and gave some hints to Jader when it first appeared 
on the libfuse mailing list some months ago.


Signed-off-by: Luca Risolia <luca.riso...@studio.unibo.it>

Jader H. Silva wrote:

Implement cuse mmap using shmem to provide the actual memory maps.
Pages must be read/written using fuse's NOTIFY_RETRIEVE and NOTIFY_STORE api.

Signed-off-by: Jader H. Silva <jader...@gmail.com>
---
  fs/fuse/cuse.c| 459 +-
  fs/fuse/dev.c | 163 +---
  fs/fuse/fuse_i.h  |  34 +++-
  fs/fuse/inode.c   | 166 -
  include/uapi/linux/fuse.h |  26 +++
  5 files changed, 688 insertions(+), 160 deletions(-)

diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c
index eae2c11..7749c13 100644
--- a/fs/fuse/cuse.c
+++ b/fs/fuse/cuse.c
@@ -48,6 +48,9 @@
  #include 
  #include 
  #include 
+#include 
+#include 
+#include 

  #include "fuse_i.h"

@@ -175,6 +178,441 @@ static long cuse_file_compat_ioctl(struct file *file, 
unsigned int cmd,
return fuse_do_ioctl(file, cmd, arg, flags);
  }

+struct fuse_dmmap_region {
+   u64 mapid;
+   u64 size;
+   struct file *filp;
+   struct vm_operations_struct vm_ops;
+   const struct vm_operations_struct *vm_original_ops;
+   struct list_head list;
+   atomic_t ref;
+};
+
+/*
+ * fuse_dmmap_vm represents the result of a single mmap() call, which
+ * can be shared by multiple client vmas created by forking.
+ */
+struct fuse_dmmap_vm {
+   u64 len;
+   u64 off;
+   atomic_t open_count;
+   struct fuse_dmmap_region *region;
+};
+
+static void fuse_dmmap_region_put(struct fuse_conn *fc,
+ struct fuse_dmmap_region *fdr)
+{
+   if (atomic_dec_and_lock(>ref, >lock)) {
+
+   list_del(>list);
+
+   spin_unlock(>lock);
+
+   fput(fdr->filp);
+   kfree(fdr);
+   }
+}
+
+static void fuse_dmmap_vm_open(struct vm_area_struct *vma)
+{
+   struct fuse_dmmap_vm *fdvm = vma->vm_private_data;
+   struct fuse_dmmap_region *fdr = fdvm->region;
+
+   /* vma copied */
+   atomic_inc(>open_count);
+
+   if (fdr->vm_original_ops->open)
+   fdr->vm_original_ops->open(vma);
+}
+
+static void fuse_dmmap_vm_close(struct vm_area_struct *vma)
+{
+   struct fuse_dmmap_vm *fdvm = vma->vm_private_data;
+   struct fuse_dmmap_region *fdr = fdvm->region;
+   struct fuse_file *ff = vma->vm_file->private_data;
+   struct fuse_conn *fc = ff->fc;
+   struct fuse_req *req;
+   struct fuse_munmap_in *inarg;
+
+   if (fdr->vm_original_ops->close)
+   fdr->vm_original_ops->close(vma);
+
+   if (!atomic_dec_and_test(>open_count))
+   return;
+
+   /*
+* Notify server that the mmap region has been unmapped.
+* Failing this might lead to resource leak in server, don't
+* fail.
+*/
+   req = fuse_get_req_nofail_nopages(fc, vma->vm_file);
+   inarg = >misc.munmap_in;
+
+   inarg->fh = ff->fh;
+   inarg->mapid = fdvm->region->mapid;
+   inarg->size = fdvm->len;
+   inarg->offset = fdvm->off;
+
+   req->in.h.opcode = FUSE_MUNMAP;
+   req->in.h.nodeid = ff->nodeid;
+   req->in.numargs = 1;
+   req->in.args[0].size = sizeof(*inarg);
+   req->in.args[0].value = inarg;
+
+   fuse_request_send(fc, req);
+   fuse_put_request(fc, req);
+   fuse_dmmap_region_put(fc, fdvm->region);
+   kfree(fdvm);
+}
+
+static int fuse_dmmap_vm_fault(struct vm_area_struct *vma, struct vm_fault 
*vmf)
+{
+   int ret;
+   struct file *filp = vma->vm_file;
+   struct fuse_dmmap_vm *fdvm = vma->vm_private_data;
+   struct fuse_dmmap_region *fdr = fdvm->region;
+
+   vma->vm_file = fdr->filp;
+   ret = fdr->vm_original_ops->fault(vma, vmf);
+
+   vma->vm_file = filp;
+
+   return ret;
+}
+
+static const struct vm_operations_struct fuse_dmmap_vm_ops = {
+   .open   = fuse_dmmap_vm_open,
+   .close  = fuse_dmmap_vm_close,
+   .fault  = fuse_dmmap_vm_fault,
+};
+
+static struct fuse_dmmap_region *fuse_dmmap_find_locked(struct fuse_conn *fc,
+   u64 mapid)
+{
+   struct fuse_dmmap_region *curr;
+   struct fuse_dmmap_region *fdr = NULL;
+
+   list_for_each_entry(curr, >dmmap_list, list) {
+   if (curr->mapid == mapid) {
+   fdr = curr;
+   atomic_inc(>ref);
+   break;
+   }
+   }
+
+   return fdr;
+}
+
+static struct fuse_dmmap_region *fuse_dmmap_find(struct fuse_conn *fc,
+u64 mapid)
+{
+   st

What to do when maintainers are unavailable?

[Luca Risolia]

Hi people,

we properly submitted some kernel patches (adding mmap support to CUSE) 
to the FUSE mailing list some months ago and have been asking for their 
inclusion in the FUSE tree since then, but got no feedbacks, no replies 
at all from the maintainers. We would like to have these patches 
reviewed and possibly included in the mainline kernel in reasonable time.


Who should we submit our patches to in this case, as silence from the 
maintainers is not going to help?


Thanks

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

What to do when maintainers are unavailable?

[Luca Risolia]

Hi people,

we properly submitted some kernel patches (adding mmap support to CUSE) 
to the FUSE mailing list some months ago and have been asking for their 
inclusion in the FUSE tree since then, but got no feedbacks, no replies 
at all from the maintainers. We would like to have these patches 
reviewed and possibly included in the mainline kernel in reasonable time.


Who should we submit our patches to in this case, as silence from the 
maintainers is not going to help?


Thanks

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

Re: [PATCH 2/3] drivers/media/video/sn9c102/sn9c102_core.c Fix Unlikely(x) == y

[Luca Risolia]

It's okay, thanks.

Reviewed-by: Luca Risolia <[EMAIL PROTECTED]>
---

On Saturday 16 February 2008 17:12:26 Roel Kluin wrote:
> The patch below was not yet tested. If it's incorrect, please comment.
> ---
> Fix Unlikely(x) == y
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/media/video/sn9c102/sn9c102_core.c
> b/drivers/media/video/sn9c102/sn9c102_core.c index c40ba3a..66313b1 100644
> --- a/drivers/media/video/sn9c102/sn9c102_core.c
> +++ b/drivers/media/video/sn9c102/sn9c102_core.c
> @@ -528,7 +528,7 @@ sn9c102_find_sof_header(struct sn9c102_device* cam,
> void* mem, size_t len)
>
>   /* Search for the SOF marker (fixed part) in the header */
>   for (j = 0, b=cam->sof.bytesread; j+b < sizeof(marker); j++) {
> - if (unlikely(i+j) == len)
> + if (unlikely(i+j == len))
>   return NULL;
>   if (*(m+i+j) == marker[cam->sof.bytesread]) {
>   cam->sof.header[cam->sof.bytesread] = *(m+i+j);


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

Re: [PATCH 2/3] drivers/media/video/sn9c102/sn9c102_core.c Fix Unlikely(x) == y

[Luca Risolia]

It's okay, thanks.

Reviewed-by: Luca Risolia [EMAIL PROTECTED]
---

On Saturday 16 February 2008 17:12:26 Roel Kluin wrote:
 The patch below was not yet tested. If it's incorrect, please comment.
 ---
 Fix Unlikely(x) == y

 Signed-off-by: Roel Kluin [EMAIL PROTECTED]
 ---
 diff --git a/drivers/media/video/sn9c102/sn9c102_core.c
 b/drivers/media/video/sn9c102/sn9c102_core.c index c40ba3a..66313b1 100644
 --- a/drivers/media/video/sn9c102/sn9c102_core.c
 +++ b/drivers/media/video/sn9c102/sn9c102_core.c
 @@ -528,7 +528,7 @@ sn9c102_find_sof_header(struct sn9c102_device* cam,
 void* mem, size_t len)

   /* Search for the SOF marker (fixed part) in the header */
   for (j = 0, b=cam-sof.bytesread; j+b  sizeof(marker); j++) {
 - if (unlikely(i+j) == len)
 + if (unlikely(i+j == len))
   return NULL;
   if (*(m+i+j) == marker[cam-sof.bytesread]) {
   cam-sof.header[cam-sof.bytesread] = *(m+i+j);


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

Re: [PATCH 2/3] V4L: zc0301, remove bad usage of ERESTARTSYS

[Luca Risolia]

acked-by: Luca Risolia <[EMAIL PROTECTED]>


On Monday 08 October 2007 14:40:53 Jiri Slaby wrote:
> zc0301, remove bad usage of ERESTARTSYS
>
> down_read_trylock can't be interrupted and so ERESTARTSYS would reach
> userspace, which is not permitted. Change it to EAGAIN
>
> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
>
> ---
> commit 235cf594bc65128250632a642f3e9d7e4df4975e
> tree 0557746416827daeb4d829610fec2f0c9111a675
> parent db38c559d37219c32b179ae005ca7e489336ec94
> author Jiri Slaby <[EMAIL PROTECTED]> Mon, 08 Oct 2007 14:15:47 +0200
> committer Jiri Slaby <[EMAIL PROTECTED]> Mon, 08 Oct 2007 14:15:47 +0200
>
>  drivers/media/video/zc0301/zc0301_core.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/video/zc0301/zc0301_core.c
> b/drivers/media/video/zc0301/zc0301_core.c index 35138c5..08a93c3 100644
> --- a/drivers/media/video/zc0301/zc0301_core.c
> +++ b/drivers/media/video/zc0301/zc0301_core.c
> @@ -655,7 +655,7 @@ static int zc0301_open(struct inode* inode, struct
> file* filp) int err = 0;
>
>   if (!down_read_trylock(_dev_lock))
> - return -ERESTARTSYS;
> + return -EAGAIN;
>
>   cam = video_get_drvdata(video_devdata(filp));


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

Re: [PATCH 1/3] V4L: w9968cf, remove bad usage of ERESTARTSYS

[Luca Risolia]

acked-by: Luca Risolia <[EMAIL PROTECTED]>

On Monday 08 October 2007 14:40:13 Jiri Slaby wrote:
> w9968cf, remove bad usage of ERESTARTSYS
>
> down_read_trylock can't be interrupted and so ERESTARTSYS would reach
> userspace, which is not permitted. Change it to EAGAIN
>
> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
>
> ---
> commit db38c559d37219c32b179ae005ca7e489336ec94
> tree f2d606165e6ef2daa6e1a2860f87521222eeecd2
> parent 6e42c2183befe136d85e6a8708ee4eabc543774b
> author Jiri Slaby <[EMAIL PROTECTED]> Mon, 08 Oct 2007 14:14:03 +0200
> committer Jiri Slaby <[EMAIL PROTECTED]> Mon, 08 Oct 2007 14:14:03 +0200
>
>  drivers/media/video/w9968cf.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/video/w9968cf.c b/drivers/media/video/w9968cf.c
> index 77599f2..5a1b5f5 100644
> --- a/drivers/media/video/w9968cf.c
> +++ b/drivers/media/video/w9968cf.c
> @@ -2679,7 +2679,7 @@ static int w9968cf_open(struct inode* inode, struct
> file* filp)
>
>   /* This the only safe way to prevent race conditions with disconnect */
>   if (!down_read_trylock(_disconnect))
> - return -ERESTARTSYS;
> + return -EAGAIN;
>
>   cam = (struct w9968cf_device*)video_get_drvdata(video_devdata(filp));


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

Re: [PATCH 1/3] V4L: w9968cf, remove bad usage of ERESTARTSYS

[Luca Risolia]

acked-by: Luca Risolia [EMAIL PROTECTED]

On Monday 08 October 2007 14:40:13 Jiri Slaby wrote:
 w9968cf, remove bad usage of ERESTARTSYS

 down_read_trylock can't be interrupted and so ERESTARTSYS would reach
 userspace, which is not permitted. Change it to EAGAIN

 Signed-off-by: Jiri Slaby [EMAIL PROTECTED]

 ---
 commit db38c559d37219c32b179ae005ca7e489336ec94
 tree f2d606165e6ef2daa6e1a2860f87521222eeecd2
 parent 6e42c2183befe136d85e6a8708ee4eabc543774b
 author Jiri Slaby [EMAIL PROTECTED] Mon, 08 Oct 2007 14:14:03 +0200
 committer Jiri Slaby [EMAIL PROTECTED] Mon, 08 Oct 2007 14:14:03 +0200

  drivers/media/video/w9968cf.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/media/video/w9968cf.c b/drivers/media/video/w9968cf.c
 index 77599f2..5a1b5f5 100644
 --- a/drivers/media/video/w9968cf.c
 +++ b/drivers/media/video/w9968cf.c
 @@ -2679,7 +2679,7 @@ static int w9968cf_open(struct inode* inode, struct
 file* filp)

   /* This the only safe way to prevent race conditions with disconnect */
   if (!down_read_trylock(w9968cf_disconnect))
 - return -ERESTARTSYS;
 + return -EAGAIN;

   cam = (struct w9968cf_device*)video_get_drvdata(video_devdata(filp));


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

Re: [PATCH 2/3] V4L: zc0301, remove bad usage of ERESTARTSYS

[Luca Risolia]

acked-by: Luca Risolia [EMAIL PROTECTED]


On Monday 08 October 2007 14:40:53 Jiri Slaby wrote:
 zc0301, remove bad usage of ERESTARTSYS

 down_read_trylock can't be interrupted and so ERESTARTSYS would reach
 userspace, which is not permitted. Change it to EAGAIN

 Signed-off-by: Jiri Slaby [EMAIL PROTECTED]

 ---
 commit 235cf594bc65128250632a642f3e9d7e4df4975e
 tree 0557746416827daeb4d829610fec2f0c9111a675
 parent db38c559d37219c32b179ae005ca7e489336ec94
 author Jiri Slaby [EMAIL PROTECTED] Mon, 08 Oct 2007 14:15:47 +0200
 committer Jiri Slaby [EMAIL PROTECTED] Mon, 08 Oct 2007 14:15:47 +0200

  drivers/media/video/zc0301/zc0301_core.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/media/video/zc0301/zc0301_core.c
 b/drivers/media/video/zc0301/zc0301_core.c index 35138c5..08a93c3 100644
 --- a/drivers/media/video/zc0301/zc0301_core.c
 +++ b/drivers/media/video/zc0301/zc0301_core.c
 @@ -655,7 +655,7 @@ static int zc0301_open(struct inode* inode, struct
 file* filp) int err = 0;

   if (!down_read_trylock(zc0301_dev_lock))
 - return -ERESTARTSYS;
 + return -EAGAIN;

   cam = video_get_drvdata(video_devdata(filp));


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

Re: [PATCH] v4l: fix build error for et61x251 driver

[Luca Risolia]

_version,
> NULL); usbvision-video.c:static CLASS_DEVICE_ATTR(model, S_IRUGO,
> show_model, NULL); usbvision-video.c:static CLASS_DEVICE_ATTR(hue, S_IRUGO,
> show_hue, NULL); usbvision-video.c:static CLASS_DEVICE_ATTR(contrast,
> S_IRUGO, show_contrast, NULL); usbvision-video.c:static
> CLASS_DEVICE_ATTR(brightness, S_IRUGO, show_brightness, NULL);
> usbvision-video.c:static CLASS_DEVICE_ATTR(saturation, S_IRUGO,
> show_saturation, NULL); usbvision-video.c:static
> CLASS_DEVICE_ATTR(streaming, S_IRUGO, show_streaming, NULL);
> usbvision-video.c:static CLASS_DEVICE_ATTR(compression, S_IRUGO,
> show_compression, NULL); usbvision-video.c:static CLASS_DEVICE_ATTR(bridge,
> S_IRUGO, show_device_bridge, NULL);
>
> From the above, you can clearly see that et62x251 and s9c102 provides an
> interface to directly change a register at the device. The other drivers
> allows reading/changing a few controls directly via /proc (this is also
> possible, using V4L2 interface). This is not recommended, since V4L2 API
> should be the proper way to control the devices.


through ioctl()? It's not as immediate and safe as controlling the device 
registers through /sysfs (not /proc). However, the sysfs interface in those 
drivers appeared before V4L2 had its own ioctls and we agreed to keep and 
export the interface to the only users selecting CONFIG_VIDEO_ADV_DEBUG (ok, 
this is actually valid for the sn9c102, I'll submit a patch for the et61x251 
in the future). 


> From my POV, a driver that is creating its own userspace API is not
> fully compliant with V4L2 API.

Isn't Video4Linux2 ioctl() supersedeing sysfs in this case?


> Cheers,
> Mauro

Best regards
Luca Risolia

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

Re: [PATCH] v4l: fix build error for et61x251 driver

[Luca Risolia]

,
 show_compression, NULL); usbvision-video.c:static CLASS_DEVICE_ATTR(bridge,
 S_IRUGO, show_device_bridge, NULL);

 From the above, you can clearly see that et62x251 and s9c102 provides an
 interface to directly change a register at the device. The other drivers
 allows reading/changing a few controls directly via /proc (this is also
 possible, using V4L2 interface). This is not recommended, since V4L2 API
 should be the proper way to control the devices.


through ioctl()? It's not as immediate and safe as controlling the device 
registers through /sysfs (not /proc). However, the sysfs interface in those 
drivers appeared before V4L2 had its own ioctls and we agreed to keep and 
export the interface to the only users selecting CONFIG_VIDEO_ADV_DEBUG (ok, 
this is actually valid for the sn9c102, I'll submit a patch for the et61x251 
in the future). 


 From my POV, a driver that is creating its own userspace API is not
 fully compliant with V4L2 API.

Isn't Video4Linux2 ioctl() supersedeing sysfs in this case?


 Cheers,
 Mauro

Best regards
Luca Risolia

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

Re: [PATCH] v4l: fix build error for et61x251 driver

[Luca Risolia]

On Friday 14 September 2007 02:09:01 Linus Torvalds wrote:
> On Fri, 14 Sep 2007, Luca Risolia wrote:
> > Hacked-by: Luca Risolia <[EMAIL PROTECTED]>
> >
> > On Friday 14 September 2007 00:27:17 Andreas Herrmann wrote:
> > > This fixes a kernel build problem and
> > > should make it into 2.6.23, I think.
> > >
> > >
> > > Regards,
> > >
> > > Andreas
> > >
> > > --
> > >
> > > Get rid of some v4l1 remainders to avoid kernel build errors if
> > > V4L1_COMPAT is not selected:
> > >
> > >   drivers/media/video/et61x251/et61x251_core.c: In et61x251_show_:
> > >   drivers/media/video/et61x251/et61x251_core.c:718: error: implicit
> > > declaration of to_video_device
> > >
> > > Fix as suggested by  Luca Risolia <[EMAIL PROTECTED]>
>
> This patch is really ugly.
>
> Why can't the "to_video_device()" macro be used? Just move it to a place
> where it's usable! IOW, what's wrong with the *much* simpler patch below?

There's nothing wtong in my opinion. I do not know the exact reason why Mauro 
moved "to_video_device()" into CONFIG_VIDEO_V4L1_COMPAT. Pheraps he can give 
more details about this change.


> That "to_video_device()" macro has absolutely _nothing_ to do with
> CONFIG_VIDEO_V4L1_COMPAT, as far as I can tell!
>
>   Linus
> ---
> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
> index d62847f..17f8f3a 100644
> --- a/include/media/v4l2-dev.h
> +++ b/include/media/v4l2-dev.h
> @@ -337,6 +337,9 @@ void *priv;
>   struct class_device class_dev; /* sysfs */
>  };
>
> +/* Class-dev to video-device */
> +#define to_video_device(cd) container_of(cd, struct video_device,
> class_dev) +
>  /* Version 2 functions */
>  extern int video_register_device(struct video_device *vfd, int type, int
> nr); void video_unregister_device(struct video_device *);
> @@ -354,11 +357,9 @@ extern int video_usercopy(struct inode *inode, struct
> file *file, int (*func)(struct inode *inode, struct file *file,
> unsigned int cmd, void *arg));
>
> -
>  #ifdef CONFIG_VIDEO_V4L1_COMPAT
>  #include 
>
> -#define to_video_device(cd) container_of(cd, struct video_device,
> class_dev) static inline int __must_check
>  video_device_create_file(struct video_device *vfd,
>struct class_device_attribute *attr)

Best regards
Luca Risolia
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] v4l: fix build error for et61x251 driver

[Luca Risolia]

Hacked-by: Luca Risolia <[EMAIL PROTECTED]>

On Friday 14 September 2007 00:27:17 Andreas Herrmann wrote:
> This fixes a kernel build problem and
> should make it into 2.6.23, I think.
>
>
> Regards,
>
> Andreas
>
> --
>
> Get rid of some v4l1 remainders to avoid kernel build errors if
> V4L1_COMPAT is not selected:
>
>   drivers/media/video/et61x251/et61x251_core.c: In et61x251_show_:
>   drivers/media/video/et61x251/et61x251_core.c:718: error: implicit
> declaration of to_video_device
>
> Fix as suggested by  Luca Risolia <[EMAIL PROTECTED]>
>
> Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
> ---
>  drivers/media/video/et61x251/et61x251_core.c |   24
>  1 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/video/et61x251/et61x251_core.c
> b/drivers/media/video/et61x251/et61x251_core.c index 585bd1f..a3ee968
> 100644
> --- a/drivers/media/video/et61x251/et61x251_core.c
> +++ b/drivers/media/video/et61x251/et61x251_core.c
> @@ -715,7 +715,8 @@ static ssize_t et61x251_show_reg(struct class_device*
> cd, char* buf) if (mutex_lock_interruptible(_sysfs_lock))
>   return -ERESTARTSYS;
>
> - cam = video_get_drvdata(to_video_device(cd));
> + cam = video_get_drvdata(container_of(cd, struct video_device,
> +  class_dev));
>   if (!cam) {
>   mutex_unlock(_sysfs_lock);
>   return -ENODEV;
> @@ -739,7 +740,8 @@ et61x251_store_reg(struct class_device* cd, const char*
> buf, size_t len) if (mutex_lock_interruptible(_sysfs_lock))
>   return -ERESTARTSYS;
>
> - cam = video_get_drvdata(to_video_device(cd));
> + cam = video_get_drvdata(container_of(cd, struct video_device,
> +  class_dev));
>   if (!cam) {
>   mutex_unlock(_sysfs_lock);
>   return -ENODEV;
> @@ -771,7 +773,8 @@ static ssize_t et61x251_show_val(struct class_device*
> cd, char* buf) if (mutex_lock_interruptible(_sysfs_lock))
>   return -ERESTARTSYS;
>
> - cam = video_get_drvdata(to_video_device(cd));
> + cam = video_get_drvdata(container_of(cd, struct video_device,
> +  class_dev));
>   if (!cam) {
>   mutex_unlock(_sysfs_lock);
>   return -ENODEV;
> @@ -803,7 +806,8 @@ et61x251_store_val(struct class_device* cd, const char*
> buf, size_t len) if (mutex_lock_interruptible(_sysfs_lock))
>   return -ERESTARTSYS;
>
> - cam = video_get_drvdata(to_video_device(cd));
> + cam = video_get_drvdata(container_of(cd, struct video_device,
> +  class_dev));
>   if (!cam) {
>   mutex_unlock(_sysfs_lock);
>   return -ENODEV;
> @@ -839,7 +843,8 @@ static ssize_t et61x251_show_i2c_reg(struct
> class_device* cd, char* buf) if
> (mutex_lock_interruptible(_sysfs_lock))
>   return -ERESTARTSYS;
>
> - cam = video_get_drvdata(to_video_device(cd));
> + cam = video_get_drvdata(container_of(cd, struct video_device,
> +  class_dev));
>   if (!cam) {
>   mutex_unlock(_sysfs_lock);
>   return -ENODEV;
> @@ -865,7 +870,8 @@ et61x251_store_i2c_reg(struct class_device* cd, const
> char* buf, size_t len) if (mutex_lock_interruptible(_sysfs_lock))
>   return -ERESTARTSYS;
>
> - cam = video_get_drvdata(to_video_device(cd));
> + cam = video_get_drvdata(container_of(cd, struct video_device,
> +  class_dev));
>   if (!cam) {
>   mutex_unlock(_sysfs_lock);
>   return -ENODEV;
> @@ -897,7 +903,8 @@ static ssize_t et61x251_show_i2c_val(struct
> class_device* cd, char* buf) if
> (mutex_lock_interruptible(_sysfs_lock))
>   return -ERESTARTSYS;
>
> - cam = video_get_drvdata(to_video_device(cd));
> + cam = video_get_drvdata(container_of(cd, struct video_device,
> +  class_dev));
>   if (!cam) {
>   mutex_unlock(_sysfs_lock);
>   return -ENODEV;
> @@ -934,7 +941,8 @@ et61x251_store_i2c_val(struct class_device* cd, const
> char* buf, size_t len) if (mutex_lock_interruptible(_sysfs_lock))
>   return -ERESTARTSYS;
>
> - cam = video_get_drvdata(to_video_device(cd));
> + cam = video_get_drvdata(container_of(cd, struct video_device,
> +  class_dev));
>   if (!cam) {
>   mutex_unlock(_sysfs_lock);
>   return -ENODEV;


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

Re: [PATCH] v4l: Build error with et61x251, if V4L1_COMPAT is not selected

[Luca Risolia]

On Thursday 13 September 2007 14:36:27 [EMAIL PROTECTED] wrote:
> With current git tree I get an build error
> for et61x251, if V4L1_COMPAT is not selected:
>
> drivers/media/video/et61x251/et61x251_core.c: In et61x251_show_:
> drivers/media/video/et61x251/et61x251_core.c:718: error: implicit
> declaration of to_video_device
>
> Fix: add VIDEO_V4L1_COMPAT as a dependency for this driver.

No, wait. The driver really is V4L2 only. If you can, please fix it by 
replacing to_video_device() with container_of() instead:

cam = video_get_drvdata(container_of(cd, struct video_device, class_dev));

Best regards
Luca Risolia

>
> Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
> ---
>  drivers/media/video/et61x251/Kconfig |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/video/et61x251/Kconfig
> b/drivers/media/video/et61x251/Kconfig index dcc1a03..9143424 100644
> --- a/drivers/media/video/et61x251/Kconfig
> +++ b/drivers/media/video/et61x251/Kconfig
> @@ -1,6 +1,6 @@
>  config USB_ET61X251
>   tristate "USB ET61X[12]51 PC Camera Controller support"
> - depends on VIDEO_V4L2
> + depends on VIDEO_V4L2 && VIDEO_V4L1_COMPAT
>   ---help---
> Say Y here if you want support for cameras based on Etoms ET61X151
> or ET61X251 PC Camera Controllers.


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

Re: [PATCH] v4l: Build error with et61x251, if V4L1_COMPAT is not selected

[Luca Risolia]

On Thursday 13 September 2007 14:36:27 [EMAIL PROTECTED] wrote:
 With current git tree I get an build error
 for et61x251, if V4L1_COMPAT is not selected:

 drivers/media/video/et61x251/et61x251_core.c: In et61x251_show_:
 drivers/media/video/et61x251/et61x251_core.c:718: error: implicit
 declaration of to_video_device

 Fix: add VIDEO_V4L1_COMPAT as a dependency for this driver.

No, wait. The driver really is V4L2 only. If you can, please fix it by 
replacing to_video_device() with container_of() instead:

cam = video_get_drvdata(container_of(cd, struct video_device, class_dev));

Best regards
Luca Risolia


 Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
 ---
  drivers/media/video/et61x251/Kconfig |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/media/video/et61x251/Kconfig
 b/drivers/media/video/et61x251/Kconfig index dcc1a03..9143424 100644
 --- a/drivers/media/video/et61x251/Kconfig
 +++ b/drivers/media/video/et61x251/Kconfig
 @@ -1,6 +1,6 @@
  config USB_ET61X251
   tristate USB ET61X[12]51 PC Camera Controller support
 - depends on VIDEO_V4L2
 + depends on VIDEO_V4L2  VIDEO_V4L1_COMPAT
   ---help---
 Say Y here if you want support for cameras based on Etoms ET61X151
 or ET61X251 PC Camera Controllers.


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

Re: [PATCH] v4l: fix build error for et61x251 driver

[Luca Risolia]

Hacked-by: Luca Risolia [EMAIL PROTECTED]

On Friday 14 September 2007 00:27:17 Andreas Herrmann wrote:
 This fixes a kernel build problem and
 should make it into 2.6.23, I think.


 Regards,

 Andreas

 --

 Get rid of some v4l1 remainders to avoid kernel build errors if
 V4L1_COMPAT is not selected:

   drivers/media/video/et61x251/et61x251_core.c: In et61x251_show_:
   drivers/media/video/et61x251/et61x251_core.c:718: error: implicit
 declaration of to_video_device

 Fix as suggested by  Luca Risolia [EMAIL PROTECTED]

 Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
 ---
  drivers/media/video/et61x251/et61x251_core.c |   24
  1 files changed, 16 insertions(+), 8 deletions(-)

 diff --git a/drivers/media/video/et61x251/et61x251_core.c
 b/drivers/media/video/et61x251/et61x251_core.c index 585bd1f..a3ee968
 100644
 --- a/drivers/media/video/et61x251/et61x251_core.c
 +++ b/drivers/media/video/et61x251/et61x251_core.c
 @@ -715,7 +715,8 @@ static ssize_t et61x251_show_reg(struct class_device*
 cd, char* buf) if (mutex_lock_interruptible(et61x251_sysfs_lock))
   return -ERESTARTSYS;

 - cam = video_get_drvdata(to_video_device(cd));
 + cam = video_get_drvdata(container_of(cd, struct video_device,
 +  class_dev));
   if (!cam) {
   mutex_unlock(et61x251_sysfs_lock);
   return -ENODEV;
 @@ -739,7 +740,8 @@ et61x251_store_reg(struct class_device* cd, const char*
 buf, size_t len) if (mutex_lock_interruptible(et61x251_sysfs_lock))
   return -ERESTARTSYS;

 - cam = video_get_drvdata(to_video_device(cd));
 + cam = video_get_drvdata(container_of(cd, struct video_device,
 +  class_dev));
   if (!cam) {
   mutex_unlock(et61x251_sysfs_lock);
   return -ENODEV;
 @@ -771,7 +773,8 @@ static ssize_t et61x251_show_val(struct class_device*
 cd, char* buf) if (mutex_lock_interruptible(et61x251_sysfs_lock))
   return -ERESTARTSYS;

 - cam = video_get_drvdata(to_video_device(cd));
 + cam = video_get_drvdata(container_of(cd, struct video_device,
 +  class_dev));
   if (!cam) {
   mutex_unlock(et61x251_sysfs_lock);
   return -ENODEV;
 @@ -803,7 +806,8 @@ et61x251_store_val(struct class_device* cd, const char*
 buf, size_t len) if (mutex_lock_interruptible(et61x251_sysfs_lock))
   return -ERESTARTSYS;

 - cam = video_get_drvdata(to_video_device(cd));
 + cam = video_get_drvdata(container_of(cd, struct video_device,
 +  class_dev));
   if (!cam) {
   mutex_unlock(et61x251_sysfs_lock);
   return -ENODEV;
 @@ -839,7 +843,8 @@ static ssize_t et61x251_show_i2c_reg(struct
 class_device* cd, char* buf) if
 (mutex_lock_interruptible(et61x251_sysfs_lock))
   return -ERESTARTSYS;

 - cam = video_get_drvdata(to_video_device(cd));
 + cam = video_get_drvdata(container_of(cd, struct video_device,
 +  class_dev));
   if (!cam) {
   mutex_unlock(et61x251_sysfs_lock);
   return -ENODEV;
 @@ -865,7 +870,8 @@ et61x251_store_i2c_reg(struct class_device* cd, const
 char* buf, size_t len) if (mutex_lock_interruptible(et61x251_sysfs_lock))
   return -ERESTARTSYS;

 - cam = video_get_drvdata(to_video_device(cd));
 + cam = video_get_drvdata(container_of(cd, struct video_device,
 +  class_dev));
   if (!cam) {
   mutex_unlock(et61x251_sysfs_lock);
   return -ENODEV;
 @@ -897,7 +903,8 @@ static ssize_t et61x251_show_i2c_val(struct
 class_device* cd, char* buf) if
 (mutex_lock_interruptible(et61x251_sysfs_lock))
   return -ERESTARTSYS;

 - cam = video_get_drvdata(to_video_device(cd));
 + cam = video_get_drvdata(container_of(cd, struct video_device,
 +  class_dev));
   if (!cam) {
   mutex_unlock(et61x251_sysfs_lock);
   return -ENODEV;
 @@ -934,7 +941,8 @@ et61x251_store_i2c_val(struct class_device* cd, const
 char* buf, size_t len) if (mutex_lock_interruptible(et61x251_sysfs_lock))
   return -ERESTARTSYS;

 - cam = video_get_drvdata(to_video_device(cd));
 + cam = video_get_drvdata(container_of(cd, struct video_device,
 +  class_dev));
   if (!cam) {
   mutex_unlock(et61x251_sysfs_lock);
   return -ENODEV;


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

Re: [PATCH] v4l: fix build error for et61x251 driver

[Luca Risolia]

On Friday 14 September 2007 02:09:01 Linus Torvalds wrote:
 On Fri, 14 Sep 2007, Luca Risolia wrote:
  Hacked-by: Luca Risolia [EMAIL PROTECTED]
 
  On Friday 14 September 2007 00:27:17 Andreas Herrmann wrote:
   This fixes a kernel build problem and
   should make it into 2.6.23, I think.
  
  
   Regards,
  
   Andreas
  
   --
  
   Get rid of some v4l1 remainders to avoid kernel build errors if
   V4L1_COMPAT is not selected:
  
 drivers/media/video/et61x251/et61x251_core.c: In et61x251_show_:
 drivers/media/video/et61x251/et61x251_core.c:718: error: implicit
   declaration of to_video_device
  
   Fix as suggested by  Luca Risolia [EMAIL PROTECTED]

 This patch is really ugly.

 Why can't the to_video_device() macro be used? Just move it to a place
 where it's usable! IOW, what's wrong with the *much* simpler patch below?

There's nothing wtong in my opinion. I do not know the exact reason why Mauro 
moved to_video_device() into CONFIG_VIDEO_V4L1_COMPAT. Pheraps he can give 
more details about this change.


 That to_video_device() macro has absolutely _nothing_ to do with
 CONFIG_VIDEO_V4L1_COMPAT, as far as I can tell!

   Linus
 ---
 diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
 index d62847f..17f8f3a 100644
 --- a/include/media/v4l2-dev.h
 +++ b/include/media/v4l2-dev.h
 @@ -337,6 +337,9 @@ void *priv;
   struct class_device class_dev; /* sysfs */
  };

 +/* Class-dev to video-device */
 +#define to_video_device(cd) container_of(cd, struct video_device,
 class_dev) +
  /* Version 2 functions */
  extern int video_register_device(struct video_device *vfd, int type, int
 nr); void video_unregister_device(struct video_device *);
 @@ -354,11 +357,9 @@ extern int video_usercopy(struct inode *inode, struct
 file *file, int (*func)(struct inode *inode, struct file *file,
 unsigned int cmd, void *arg));

 -
  #ifdef CONFIG_VIDEO_V4L1_COMPAT
  #include linux/mm.h

 -#define to_video_device(cd) container_of(cd, struct video_device,
 class_dev) static inline int __must_check
  video_device_create_file(struct video_device *vfd,
struct class_device_attribute *attr)

Best regards
Luca Risolia
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver

[Luca Risolia]

On Monday 28 May 2007 17:14:51 Markus Rechberger wrote:
> On 5/28/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > We don't do format conversions in kernel. Instead, you should return a
> > proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8).
>
> It's ok in his case since most userspace applications do not support
> this format, it helps noone if there's a driver out there which isn't
> supported by most userspace applications and I don't expect that all
> applications will add a conversion for that format soon.
> This would moreover raise the question about a userspace library,
> though there are many more important issues which are outstanding and
> which got smashed down.

Markus, I do think the userspace library is THE real problem with the whole 
V4L subsystem. It's annoying to keep repeating why these convertions should 
be done outside the kernel, be them in a library or not. I deliberatly never 
implemented the above convertion in the drivers that I have been maintaing 
for years, since I had the idea that this approach whould have pushed the 
developers to write the _best_ algorithm by themselves. I still think it's 
the correct approach, but now I give up. Mauro, if you are planning to accept 
this BayerToSomething color convertion, be also prepared to accept the same 
convertion for other drivers in the kernel. Rules are made for everyone.

Best regards,
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver

[Luca Risolia]

On Monday 28 May 2007 17:14:51 Markus Rechberger wrote:
 On 5/28/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
  We don't do format conversions in kernel. Instead, you should return a
  proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8).

 It's ok in his case since most userspace applications do not support
 this format, it helps noone if there's a driver out there which isn't
 supported by most userspace applications and I don't expect that all
 applications will add a conversion for that format soon.
 This would moreover raise the question about a userspace library,
 though there are many more important issues which are outstanding and
 which got smashed down.

Markus, I do think the userspace library is THE real problem with the whole 
V4L subsystem. It's annoying to keep repeating why these convertions should 
be done outside the kernel, be them in a library or not. I deliberatly never 
implemented the above convertion in the drivers that I have been maintaing 
for years, since I had the idea that this approach whould have pushed the 
developers to write the _best_ algorithm by themselves. I still think it's 
the correct approach, but now I give up. Mauro, if you are planning to accept 
this BayerToSomething color convertion, be also prepared to accept the same 
convertion for other drivers in the kernel. Rules are made for everyone.

Best regards,
Luca
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: status of the USB w9968cf.c driver in kernel 2.6?

[Luca Risolia]

Scrive Adrian Bunk <[EMAIL PROTECTED]>:

> On Tue, Mar 01, 2005 at 06:46:03PM +0100, Luca Risolia wrote:
> > Scrive Adrian Bunk <[EMAIL PROTECTED]>: 
> >  
> > > I noticed the following regarding the drivers/usb/media/ov511.c driver: 
> >   ^^^ 
> > > - it's not updated compared to upstream: 
> >  
> > Could you provide more details? 
> 
> Sorry, my fault.
> I confused this with a different driver.
> 
> > > - there's no w9968cf-vpp module in the kernel sources 
> >  
> > w9968cf-vpp is an optional, gpl'ed module, which can not be included in the
> 
> > mainline kernel, as I explained in the documentation of the driver. 
> 
>   Please keep in mind that official kernels do not include the second 
>   module for performance purposes.
> 
> What exactly does this mean?

Frame decoding/decompression should be done in userspace, although you can 
still download and use a separate kernel module.

> 
> Is it useful or not?

Yes

Regards,
Luca


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

Re: status of the USB w9968cf.c driver in kernel 2.6?

[Luca Risolia]

Scrive Adrian Bunk [EMAIL PROTECTED]:

 On Tue, Mar 01, 2005 at 06:46:03PM +0100, Luca Risolia wrote:
  Scrive Adrian Bunk [EMAIL PROTECTED]: 
   
   I noticed the following regarding the drivers/usb/media/ov511.c driver: 
^^^ 
   - it's not updated compared to upstream: 
   
  Could you provide more details? 
 
 Sorry, my fault.
 I confused this with a different driver.
 
   - there's no w9968cf-vpp module in the kernel sources 
   
  w9968cf-vpp is an optional, gpl'ed module, which can not be included in the
 
  mainline kernel, as I explained in the documentation of the driver. 
 
   Please keep in mind that official kernels do not include the second 
   module for performance purposes.
 
 What exactly does this mean?

Frame decoding/decompression should be done in userspace, although you can 
still download and use a separate kernel module.

 
 Is it useful or not?

Yes

Regards,
Luca


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

Re: status of the USB w9968cf.c driver in kernel 2.6?

[Luca Risolia]

Scrive Adrian Bunk <[EMAIL PROTECTED]>: 
 
> I noticed the following regarding the drivers/usb/media/ov511.c driver: 
  ^^^ 
> - it's not updated compared to upstream: 
 
Could you provide more details? 
 
> - there's no w9968cf-vpp module in the kernel sources 
 
w9968cf-vpp is an optional, gpl'ed module, which can not be included in the 
mainline kernel, as I explained in the documentation of the driver. 
 
Regards, 
  Luca 
 

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

Re: status of the USB w9968cf.c driver in kernel 2.6?

[Luca Risolia]

Scrive Adrian Bunk [EMAIL PROTECTED]: 
 
 I noticed the following regarding the drivers/usb/media/ov511.c driver: 
  ^^^ 
 - it's not updated compared to upstream: 
 
Could you provide more details? 
 
 - there's no w9968cf-vpp module in the kernel sources 
 
w9968cf-vpp is an optional, gpl'ed module, which can not be included in the 
mainline kernel, as I explained in the documentation of the driver. 
 
Regards, 
  Luca 
 

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