[PATCH] documentation: misc_open sets private_data for driver's open()

[Martin Kepplinger]

Signed-off-by: Martin Kepplinger <martink@xxxxxxxxx>
---
 Documentation/filesystems/vfs.txt |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/filesystems/vfs.txt
b/Documentation/filesystems/vfs.txt
index 61d65cc..06df9d9 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -869,7 +869,8 @@ otherwise noted.
 	done the way it is because it makes filesystems simpler to
 	implement. The open() method is a good place to initialize the
 	"private_data" member in the file structure if you want to point
-	to a device structure
+	to a device structure. In the case of "struct miscdevice", when
+	you implement open() this is done automatically.

   flush: called by the close(2) system call to flush a file

-- 
1.7.10.4


> 
>> misc_open() is called in any case, on open(). As long as miscdevice drivers
>> don't explicitly rely on private_data being NULL exactly IF they don't
>> implement an open() fop (which I wouldn't imagine), this would make things
>> even more convenient.
> 
> I agree, but it would be great if you can audit the existing misc
> drivers to ensure we don't break anything with this change.  Can you do
> that please?
> 

I would grep -r "struct miscdevice" ./drivers/; and look at struct
file_operations of these results, see how their open() looks like, and
where they assign something to private_data.

If you have an idea for a script that lists all relevant files for me,
please tell me.

I queue this up but can't tell at all when it actually gets scheduled in ;)

I guess some do this work on their own because they don't know that
misc_open() already does it for them. It would probably be too much to
check what drivers could then just drop their open(). Interesting though
;) But in the short term, I think the appended documentation would help.

                              martin

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