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

Greg Kroah-Hartman greg at kroah.com
Tue Nov 20 09:56:25 UTC 2018


On Tue, Nov 13, 2018 at 11:32:51AM +0800, wahahab wrote:
> 
> > On 12 Nov 2018, at 8:40 PM, Greg Kroah-Hartman <greg at kroah.com> 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 at oracle.com <mailto:dan.carpenter at oracle.com>> 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


More information about the devel mailing list