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

From: Martin Kepplinger
Date: Thu Oct 09 2014 - 08:54:28 EST

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
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


>> 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.


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/