Re: [PATCH v3] driver-staging: vsoc.c: Add sysfs support for examining the permissions of regions.

From: Greg Kroah-Hartman
Date: Tue Nov 20 2018 - 04:56:31 EST


On Tue, Nov 13, 2018 at 11:32:51AM +0800, wahahab wrote:
>
> > On 12 Nov 2018, at 8:40 PM, Greg Kroah-Hartman <greg@xxxxxxxxx> wrote:
> >
> > On Mon, Nov 12, 2018 at 04:49:30PM +0800, wahahab wrote:
> >>
> >>> On 10 Nov 2018, at 1:15 AM, Dan Carpenter <dan.carpenter@xxxxxxxxxx <mailto:dan.carpenter@xxxxxxxxxx>> wrote:
> >>>
> >>> On Wed, Nov 07, 2018 at 10:30:43AM +0800, Jerry Lin wrote:
> >>>> Add a attribute called permissions under vsoc device node for examining
> >>>> current granted permissions in vsoc_device.
> >>>>
> >>>> This file will display permissions in following format:
> >>>> begin_offset end_offset owner_offset owned_value
> >>>> %x %x %x %x
> >>>>
> >>>
> >>> (I'm not totally an expert on sysfs rules).
> >>>
> >>> Sysfs are supposed to be one value per file, so instead of doing this
> >>> you would create a directory with four files like
> >>> vsoc_device/begin_offset vsoc_device/end_offset etc. And each would
> >>> just hae a %x output.
> >>
> >> Thanks for your advice. I have started with this approach.
> >>
> >> But when I trying to create this kind of sysfs hierarchy. I encountered the difficulties of file organizing.
> >>
> >> My current thought is to create a folder under the device node called permissions and user can examine
> >> permission though file path like vsoc_device/permissions/permission1/begin_offset. But there comes a
> >> problem that it seems hard to determine the correct index of permission to make folder name unique.
> >>
> >> The solution I come up with is to use memory address of permission node to be the index of permission.
> >> So the path will be something like vsoc_device/permissions/0x4d23f/begin_offset.
> >> Is this OK for sysfs?
> >
> > Ick, that is messy. What exactly are you trying to export and why use
> > sysfs? Is this just debugging information? Who is going to use this
> > data?
>
> I felt that exporting these information in sysfs will add lots of complexities in this driver.
> And Iâm not sure these informations are for user space or just for debugging.
>
> It seems there is a conflict of TODO messages between TODO file and the
> comment in vsoc.c.
>
> Should I use debugfs first for this patch?

If it is for debugging, yes. As I have no idea what this code is doing,
or what wants that information, it is hard to determine, sorry.

good luck!

greg k-h