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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
