Re: [RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[sourab gupta]

On Mon, 2016-12-19 at 17:15 -0800, Laurent Pinchart wrote:
> Hi Swati,
> 
> On Monday 19 Dec 2016 16:12:22 swati.dhin...@intel.com wrote:
> > From: Swati Dhingra 
> >
> > Currently, we don't have a stable ABI which can be used for the purpose of
> > providing output debug/loggging/crc and other such data from DRM.
> > The ABI in current use (filesystems, ioctls, et al.) have their own
> > constraints and are intended to output a particular type of data.
> > Few cases in point:
> > sysfs - stable ABI, but constrained to one textual value per file
> > debugfs   - unstable ABI, free-for-all
> > ioctls- not as suitable to many single purpose continuous data
> > dumping, we would very quickly run out ioctl space; requires more
> > userspace support than "cat"
> > device nodes -  a real possibilty, kernel instantiation is more tricky,
> >   requires udev (+udev.rules) or userspace discovery of the
> >   dynamic major:minor (via sysfs) [mounting a registered
> >   filesystem is easy in comparison]
> > netlink   - stream based, therefore involves numerous copies.
> >
> > Debugfs is the lesser among the evils here, thereby we have grown used to
> > the convenience and flexibility in presentation that debugfs gives us
> > (including relayfs inodes) that we want some of that hierachy in stable user
> > ABI form.
> 
> Seriously, why ? A subsystem growing its own file system sounds so wrong. It
> seems that you want to have all the benefits of a stable ABI without going
> through the standardization effort that this requires. I can see so many ways
> that drmfs could be abused, with drivers throwing in new data with little or
> no review. You'll need very compelling arguments to convince me.
> 

Hi Laurent,
Can you please let us know how to address the standardization issues? As
per our (limited) knowledge, drmfs seemed to be the most suitable
solution for exposing usecases such as microprocessor logs in i915, and
possibly other such usecases, which ideally can't fit in with
sysfs/debugfs/ioctls due to reasons mentioned above.

But having said that, standardization requires a lot more effort
(defining the constraints etc.), which we're not familiar with, frankly.
Can you please provide your views on how to proceed as such, since the
idea seemed worth pursuing to us (It's a drm based filesystem, whose
existence depends on drm, and directory contents solely controlled by
the corresponding drm driver - as such the contents shouldn't be
controllable by an external driver).
Or, should this be dropped, if the idea of a subsystem having its own
filesystem is fundamentally wrong to its core?

Regards,
Sourab

> > Due to these limitations, there is a need for a new pseudo filesytem, that
> > would act as a stable 'free-for-all' ABI, with the heirarchial structure and
> > thus convenience of debugfs. This will be managed by drm, thus named
> > 'drmfs'. DRM would register this filesystem to manage a canonical
> > mountpoint, but this wouldn't limit everyone to only using that pseudofs
> > underneath.
> >
> > This can serve to hold various kinds of output data from Linux DRM
> > subsystems, for the files which can't truely fit anywhere else with
> > existing ABI's but present so, for the lack of a better place.
> >
> > In this patch series, we have introduced a pseudo filesystem named as
> > 'drmfs' for now. The filesystem is introduced in the first patch, and the
> > subsequent patches make use of the filesystem interfaces, in drm driver,
> > and making them available for use by the drm subsystem components, one of
> > which is i915. We've moved the location of i915 GuC logs from debugfs to
> > drmfs in the last patch. Subsequently, more such files such as pipe_crc,
> > error states, memory stats, etc. can be move to this filesystem, if the
> > idea introduced here is acceptable per se. The filesystem introduced is
> > being used to house the data generated by i915 driver in this patch series,
> > but will hopefully be generic enough to provide scope for usage by any
> > other drm subsystem component.
> >
> > The patch series is being floated as RFC to gather feedback on the idea and
> > infrastructure proposed here and it's suitability to address the specific
> > problem statement/use case.
> >
> > v2: fix the bat failures caused due to missing config check
> >
> > v3: Changes made:
> > - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
> > - Moving config checks to header (Chris,Daniel)
> >
> > v4: Added the kernel Documentaion (using Sphinx).
> >
> > Sourab Gupta (4):
> >   drm: Introduce drmfs pseudo filesystem interfaces
> >   drm: Register drmfs filesystem from drm init
> >   drm: Create driver specific root directory inside drmfs
> >   drm/i915: Creating guc log file in drmfs instead of debugfs
> >
> >  Documentation/gpu/drm-uapi.rst |  76 
> >  drivers/gpu/drm/Kconfig|   

Re: [RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[sourab gupta]

On Tue, 2016-12-20 at 01:44 -0800, Jani Nikula wrote:
> On Tue, 20 Dec 2016, Laurent Pinchart  
> wrote:
> > Hi Swati,
> >
> > On Monday 19 Dec 2016 16:12:22 swati.dhin...@intel.com wrote:
> >> From: Swati Dhingra 
> >>
> >> Currently, we don't have a stable ABI which can be used for the purpose of
> >> providing output debug/loggging/crc and other such data from DRM.
> >> The ABI in current use (filesystems, ioctls, et al.) have their own
> >> constraints and are intended to output a particular type of data.
> >> Few cases in point:
> >> sysfs- stable ABI, but constrained to one textual value per file
> >> debugfs  - unstable ABI, free-for-all
> >> ioctls   - not as suitable to many single purpose continuous data
> >>dumping, we would very quickly run out ioctl space; requires more
> >>userspace support than "cat"
> >> device nodes -  a real possibilty, kernel instantiation is more tricky,
> >>  requires udev (+udev.rules) or userspace discovery of the
> >>  dynamic major:minor (via sysfs) [mounting a registered
> >>  filesystem is easy in comparison]
> >> netlink  - stream based, therefore involves numerous copies.
> >>
> >> Debugfs is the lesser among the evils here, thereby we have grown used to
> >> the convenience and flexibility in presentation that debugfs gives us
> >> (including relayfs inodes) that we want some of that hierachy in stable 
> >> user
> >> ABI form.
> >
> > Seriously, why ? A subsystem growing its own file system sounds so wrong. It
> > seems that you want to have all the benefits of a stable ABI without going
> > through the standardization effort that this requires. I can see so many 
> > ways
> > that drmfs could be abused, with drivers throwing in new data with little or
> > no review. You'll need very compelling arguments to convince me.
> 
> This is not unlike my sentiments on the first version posted
> [1]. There's also the distinct feeling of [2]. Suffice it to say at this
> time that I'm dubious, not convinced enough to defend this.
> 
> Swati, please refrain from posting new versions of the patches until
> there's some consensus one way or the other; it's counter-productive to
> keep splitting off the discussion into several patch series threads at
> this stage. Let's have the discussion here.
> 
> 
> BR,
> Jani.
> 

Hi Jani,

One of the usecases we're exploring here is for pipe_crc to be
implemented over drmfs, instead of debugfs. But we're not sure whether
that'll also assuage the standardization questions/concerns.

Can you let us know how to proceed (since you've mentioned not to post
new version of patches). How do we address the standardization concerns
put forth on drmfs? Does simply having more *suitable* usecases suffice?
If not, What else should the arguments be in favor of drmfs?

Hi Chris,
Can you pitch in with your inputs in the discussion, and help address
the standardization concerns?

Regards,
Sourab

> 
> [1] http://mid.mail-archive.com/87lgw0xcf4.fsf@intel.com
> [2] https://xkcd.com/927/
> 
> >
> >> Due to these limitations, there is a need for a new pseudo filesytem, that
> >> would act as a stable 'free-for-all' ABI, with the heirarchial structure 
> >> and
> >> thus convenience of debugfs. This will be managed by drm, thus named
> >> 'drmfs'. DRM would register this filesystem to manage a canonical
> >> mountpoint, but this wouldn't limit everyone to only using that pseudofs
> >> underneath.
> >>
> >> This can serve to hold various kinds of output data from Linux DRM
> >> subsystems, for the files which can't truely fit anywhere else with
> >> existing ABI's but present so, for the lack of a better place.
> >>
> >> In this patch series, we have introduced a pseudo filesystem named as
> >> 'drmfs' for now. The filesystem is introduced in the first patch, and the
> >> subsequent patches make use of the filesystem interfaces, in drm driver,
> >> and making them available for use by the drm subsystem components, one of
> >> which is i915. We've moved the location of i915 GuC logs from debugfs to
> >> drmfs in the last patch. Subsequently, more such files such as pipe_crc,
> >> error states, memory stats, etc. can be move to this filesystem, if the
> >> idea introduced here is acceptable per se. The filesystem introduced is
> >> being used to house the data generated by i915 driver in this patch series,
> >> but will hopefully be generic enough to provide scope for usage by any
> >> other drm subsystem component.
> >>
> >> The patch series is being floated as RFC to gather feedback on the idea and
> >> infrastructure proposed here and it's suitability to address the specific
> >> problem statement/use case.
> >>
> >> v2: fix the bat failures caused due to missing config check
> >>
> >> v3: Changes made:
> >> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
> >> - Moving config checks to header 

Re: [RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[Jani Nikula]

On Thu, 09 Feb 2017, sourab gupta  wrote:
> On Tue, 2016-12-20 at 01:44 -0800, Jani Nikula wrote:
>> On Tue, 20 Dec 2016, Laurent Pinchart  
>> wrote:
>> > Hi Swati,
>> >
>> > On Monday 19 Dec 2016 16:12:22 swati.dhin...@intel.com wrote:
>> >> From: Swati Dhingra 
>> >>
>> >> Currently, we don't have a stable ABI which can be used for the purpose of
>> >> providing output debug/loggging/crc and other such data from DRM.
>> >> The ABI in current use (filesystems, ioctls, et al.) have their own
>> >> constraints and are intended to output a particular type of data.
>> >> Few cases in point:
>> >> sysfs- stable ABI, but constrained to one textual value per file
>> >> debugfs  - unstable ABI, free-for-all
>> >> ioctls   - not as suitable to many single purpose continuous data
>> >>dumping, we would very quickly run out ioctl space; requires more
>> >>userspace support than "cat"
>> >> device nodes -  a real possibilty, kernel instantiation is more tricky,
>> >>  requires udev (+udev.rules) or userspace discovery of the
>> >>  dynamic major:minor (via sysfs) [mounting a registered
>> >>  filesystem is easy in comparison]
>> >> netlink  - stream based, therefore involves numerous copies.
>> >>
>> >> Debugfs is the lesser among the evils here, thereby we have grown used to
>> >> the convenience and flexibility in presentation that debugfs gives us
>> >> (including relayfs inodes) that we want some of that hierachy in stable 
>> >> user
>> >> ABI form.
>> >
>> > Seriously, why ? A subsystem growing its own file system sounds so wrong. 
>> > It
>> > seems that you want to have all the benefits of a stable ABI without going
>> > through the standardization effort that this requires. I can see so many 
>> > ways
>> > that drmfs could be abused, with drivers throwing in new data with little 
>> > or
>> > no review. You'll need very compelling arguments to convince me.
>> 
>> This is not unlike my sentiments on the first version posted
>> [1]. There's also the distinct feeling of [2]. Suffice it to say at this
>> time that I'm dubious, not convinced enough to defend this.
>> 
>> Swati, please refrain from posting new versions of the patches until
>> there's some consensus one way or the other; it's counter-productive to
>> keep splitting off the discussion into several patch series threads at
>> this stage. Let's have the discussion here.
>> 
>> 
>> BR,
>> Jani.
>> 
>
> Hi Jani,
>
> One of the usecases we're exploring here is for pipe_crc to be
> implemented over drmfs, instead of debugfs. But we're not sure whether
> that'll also assuage the standardization questions/concerns.
>
> Can you let us know how to proceed (since you've mentioned not to post
> new version of patches). How do we address the standardization concerns
> put forth on drmfs? Does simply having more *suitable* usecases suffice?
> If not, What else should the arguments be in favor of drmfs?

I've asked not to post new versions of the patches, because the order of
business is 1) see if the idea makes sense, 2) see if the implementation
of the idea makes sense, 3) see if the implementation is polished
enough. We're still at 1), and doing more of 2) or 3) is wasted effort
if we never get past 1).

I think it's better that you try to convince *other* drm folks than me
at this point. I'm not convinced enough myself that I'd start advocating
this to others on your behalf, but I'm also not opposed enough that I'd
keep arguing after you've convinced others. I don't have the final say
on merging this or not, and even if I did I wouldn't do so without acks
from non-Intel drm folks that you need to convince anyway.

So I'm kind of saying trying convince me is a wasted effort too. ;)


BR,
Jani.


>
> Hi Chris,
> Can you pitch in with your inputs in the discussion, and help address
> the standardization concerns?
>
> Regards,
> Sourab
>
>> 
>> [1] http://mid.mail-archive.com/87lgw0xcf4.fsf@intel.com
>> [2] https://xkcd.com/927/
>> 
>> >
>> >> Due to these limitations, there is a need for a new pseudo filesytem, that
>> >> would act as a stable 'free-for-all' ABI, with the heirarchial structure 
>> >> and
>> >> thus convenience of debugfs. This will be managed by drm, thus named
>> >> 'drmfs'. DRM would register this filesystem to manage a canonical
>> >> mountpoint, but this wouldn't limit everyone to only using that pseudofs
>> >> underneath.
>> >>
>> >> This can serve to hold various kinds of output data from Linux DRM
>> >> subsystems, for the files which can't truely fit anywhere else with
>> >> existing ABI's but present so, for the lack of a better place.
>> >>
>> >> In this patch series, we have introduced a pseudo filesystem named as
>> >> 'drmfs' for now. The filesystem is introduced in the first patch, and the
>> >> subsequent patches make use of the filesystem interfaces, in drm driver,
>> >> and 

[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[Jani Nikula]

On Tue, 20 Dec 2016, Laurent Pinchart  
wrote:
> Hi Swati,
>
> On Monday 19 Dec 2016 16:12:22 swati.dhingra at intel.com wrote:
>> From: Swati Dhingra 
>> 
>> Currently, we don't have a stable ABI which can be used for the purpose of
>> providing output debug/loggging/crc and other such data from DRM.
>> The ABI in current use (filesystems, ioctls, et al.) have their own
>> constraints and are intended to output a particular type of data.
>> Few cases in point:
>> sysfs- stable ABI, but constrained to one textual value per file
>> debugfs  - unstable ABI, free-for-all
>> ioctls   - not as suitable to many single purpose continuous data
>>dumping, we would very quickly run out ioctl space; requires more
>>userspace support than "cat"
>> device nodes -  a real possibilty, kernel instantiation is more tricky,
>>  requires udev (+udev.rules) or userspace discovery of the
>>  dynamic major:minor (via sysfs) [mounting a registered
>>  filesystem is easy in comparison]
>> netlink  - stream based, therefore involves numerous copies.
>> 
>> Debugfs is the lesser among the evils here, thereby we have grown used to
>> the convenience and flexibility in presentation that debugfs gives us
>> (including relayfs inodes) that we want some of that hierachy in stable user
>> ABI form.
>
> Seriously, why ? A subsystem growing its own file system sounds so wrong. It 
> seems that you want to have all the benefits of a stable ABI without going 
> through the standardization effort that this requires. I can see so many ways 
> that drmfs could be abused, with drivers throwing in new data with little or 
> no review. You'll need very compelling arguments to convince me.

This is not unlike my sentiments on the first version posted
[1]. There's also the distinct feeling of [2]. Suffice it to say at this
time that I'm dubious, not convinced enough to defend this.

Swati, please refrain from posting new versions of the patches until
there's some consensus one way or the other; it's counter-productive to
keep splitting off the discussion into several patch series threads at
this stage. Let's have the discussion here.


BR,
Jani.


[1] http://mid.mail-archive.com/87lgw0xcf4.fsf at intel.com
[2] https://xkcd.com/927/

>
>> Due to these limitations, there is a need for a new pseudo filesytem, that
>> would act as a stable 'free-for-all' ABI, with the heirarchial structure and
>> thus convenience of debugfs. This will be managed by drm, thus named
>> 'drmfs'. DRM would register this filesystem to manage a canonical
>> mountpoint, but this wouldn't limit everyone to only using that pseudofs
>> underneath.
>> 
>> This can serve to hold various kinds of output data from Linux DRM
>> subsystems, for the files which can't truely fit anywhere else with
>> existing ABI's but present so, for the lack of a better place.
>> 
>> In this patch series, we have introduced a pseudo filesystem named as
>> 'drmfs' for now. The filesystem is introduced in the first patch, and the
>> subsequent patches make use of the filesystem interfaces, in drm driver,
>> and making them available for use by the drm subsystem components, one of
>> which is i915. We've moved the location of i915 GuC logs from debugfs to
>> drmfs in the last patch. Subsequently, more such files such as pipe_crc,
>> error states, memory stats, etc. can be move to this filesystem, if the
>> idea introduced here is acceptable per se. The filesystem introduced is
>> being used to house the data generated by i915 driver in this patch series,
>> but will hopefully be generic enough to provide scope for usage by any
>> other drm subsystem component.
>> 
>> The patch series is being floated as RFC to gather feedback on the idea and
>> infrastructure proposed here and it's suitability to address the specific
>> problem statement/use case.
>> 
>> v2: fix the bat failures caused due to missing config check
>> 
>> v3: Changes made:
>> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
>> - Moving config checks to header (Chris,Daniel)
>> 
>> v4: Added the kernel Documentaion (using Sphinx).
>> 
>> Sourab Gupta (4):
>>   drm: Introduce drmfs pseudo filesystem interfaces
>>   drm: Register drmfs filesystem from drm init
>>   drm: Create driver specific root directory inside drmfs
>>   drm/i915: Creating guc log file in drmfs instead of debugfs
>> 
>>  Documentation/gpu/drm-uapi.rst |  76 
>>  drivers/gpu/drm/Kconfig|   9 +
>>  drivers/gpu/drm/Makefile   |   1 +
>>  drivers/gpu/drm/drm_drv.c  |  26 ++
>>  drivers/gpu/drm/drmfs.c| 566 ++
>>  drivers/gpu/drm/i915/i915_guc_submission.c |  33 +-
>>  include/drm/drm_drv.h  |   3 +
>>  include/drm/drmfs.h|  77 
>>  include/uapi/linux/magic.h |   3 +
>>  9 files changed, 773 insertions(+), 21 

[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[Sean Paul]

On Tue, Dec 20, 2016 at 4:44 AM, Jani Nikula
 wrote:
> On Tue, 20 Dec 2016, Laurent Pinchart  
> wrote:
>> Hi Swati,
>>
>> On Monday 19 Dec 2016 16:12:22 swati.dhingra at intel.com wrote:
>>> From: Swati Dhingra 
>>>
>>> Currently, we don't have a stable ABI which can be used for the purpose of
>>> providing output debug/loggging/crc and other such data from DRM.
>>> The ABI in current use (filesystems, ioctls, et al.) have their own
>>> constraints and are intended to output a particular type of data.
>>> Few cases in point:
>>> sysfs- stable ABI, but constrained to one textual value per file
>>> debugfs  - unstable ABI, free-for-all
>>> ioctls   - not as suitable to many single purpose continuous data
>>>dumping, we would very quickly run out ioctl space; requires more
>>>userspace support than "cat"
>>> device nodes -  a real possibilty, kernel instantiation is more tricky,
>>>  requires udev (+udev.rules) or userspace discovery of the
>>>  dynamic major:minor (via sysfs) [mounting a registered
>>>  filesystem is easy in comparison]
>>> netlink  - stream based, therefore involves numerous copies.
>>>
>>> Debugfs is the lesser among the evils here, thereby we have grown used to
>>> the convenience and flexibility in presentation that debugfs gives us
>>> (including relayfs inodes) that we want some of that hierachy in stable user
>>> ABI form.
>>
>> Seriously, why ? A subsystem growing its own file system sounds so wrong. It
>> seems that you want to have all the benefits of a stable ABI without going
>> through the standardization effort that this requires. I can see so many ways
>> that drmfs could be abused, with drivers throwing in new data with little or
>> no review. You'll need very compelling arguments to convince me.
>
> This is not unlike my sentiments on the first version posted
> [1]. There's also the distinct feeling of [2]. Suffice it to say at this
> time that I'm dubious, not convinced enough to defend this.
>
> Swati, please refrain from posting new versions of the patches until
> there's some consensus one way or the other; it's counter-productive to
> keep splitting off the discussion into several patch series threads at
> this stage. Let's have the discussion here.
>

I'll echo Laurent's concerns here, seems like the goal is easy to
merge, hard to change. I think the problem with this is that easy to
merge usually leads to designs which need to change :)

Secondly, I'm not sure there's value outside of i915, perhaps I'm
missing use cases for other drivers.

Sean


>
> BR,
> Jani.
>
>
> [1] http://mid.mail-archive.com/87lgw0xcf4.fsf at intel.com
> [2] https://xkcd.com/927/
>
>>
>>> Due to these limitations, there is a need for a new pseudo filesytem, that
>>> would act as a stable 'free-for-all' ABI, with the heirarchial structure and
>>> thus convenience of debugfs. This will be managed by drm, thus named
>>> 'drmfs'. DRM would register this filesystem to manage a canonical
>>> mountpoint, but this wouldn't limit everyone to only using that pseudofs
>>> underneath.
>>>
>>> This can serve to hold various kinds of output data from Linux DRM
>>> subsystems, for the files which can't truely fit anywhere else with
>>> existing ABI's but present so, for the lack of a better place.
>>>
>>> In this patch series, we have introduced a pseudo filesystem named as
>>> 'drmfs' for now. The filesystem is introduced in the first patch, and the
>>> subsequent patches make use of the filesystem interfaces, in drm driver,
>>> and making them available for use by the drm subsystem components, one of
>>> which is i915. We've moved the location of i915 GuC logs from debugfs to
>>> drmfs in the last patch. Subsequently, more such files such as pipe_crc,
>>> error states, memory stats, etc. can be move to this filesystem, if the
>>> idea introduced here is acceptable per se. The filesystem introduced is
>>> being used to house the data generated by i915 driver in this patch series,
>>> but will hopefully be generic enough to provide scope for usage by any
>>> other drm subsystem component.
>>>
>>> The patch series is being floated as RFC to gather feedback on the idea and
>>> infrastructure proposed here and it's suitability to address the specific
>>> problem statement/use case.
>>>
>>> v2: fix the bat failures caused due to missing config check
>>>
>>> v3: Changes made:
>>> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
>>> - Moving config checks to header (Chris,Daniel)
>>>
>>> v4: Added the kernel Documentaion (using Sphinx).
>>>
>>> Sourab Gupta (4):
>>>   drm: Introduce drmfs pseudo filesystem interfaces
>>>   drm: Register drmfs filesystem from drm init
>>>   drm: Create driver specific root directory inside drmfs
>>>   drm/i915: Creating guc log file in drmfs instead of debugfs
>>>
>>>  Documentation/gpu/drm-uapi.rst |  76 
>>>  drivers/gpu/drm/Kconfig|   9 +
>>>  

[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[Laurent Pinchart]

Hi Swati,

On Monday 19 Dec 2016 16:12:22 swati.dhingra at intel.com wrote:
> From: Swati Dhingra 
> 
> Currently, we don't have a stable ABI which can be used for the purpose of
> providing output debug/loggging/crc and other such data from DRM.
> The ABI in current use (filesystems, ioctls, et al.) have their own
> constraints and are intended to output a particular type of data.
> Few cases in point:
> sysfs - stable ABI, but constrained to one textual value per file
> debugfs   - unstable ABI, free-for-all
> ioctls- not as suitable to many single purpose continuous data
> dumping, we would very quickly run out ioctl space; requires more
> userspace support than "cat"
> device nodes -  a real possibilty, kernel instantiation is more tricky,
>   requires udev (+udev.rules) or userspace discovery of the
>   dynamic major:minor (via sysfs) [mounting a registered
>   filesystem is easy in comparison]
> netlink   - stream based, therefore involves numerous copies.
> 
> Debugfs is the lesser among the evils here, thereby we have grown used to
> the convenience and flexibility in presentation that debugfs gives us
> (including relayfs inodes) that we want some of that hierachy in stable user
> ABI form.

Seriously, why ? A subsystem growing its own file system sounds so wrong. It 
seems that you want to have all the benefits of a stable ABI without going 
through the standardization effort that this requires. I can see so many ways 
that drmfs could be abused, with drivers throwing in new data with little or 
no review. You'll need very compelling arguments to convince me.

> Due to these limitations, there is a need for a new pseudo filesytem, that
> would act as a stable 'free-for-all' ABI, with the heirarchial structure and
> thus convenience of debugfs. This will be managed by drm, thus named
> 'drmfs'. DRM would register this filesystem to manage a canonical
> mountpoint, but this wouldn't limit everyone to only using that pseudofs
> underneath.
> 
> This can serve to hold various kinds of output data from Linux DRM
> subsystems, for the files which can't truely fit anywhere else with
> existing ABI's but present so, for the lack of a better place.
> 
> In this patch series, we have introduced a pseudo filesystem named as
> 'drmfs' for now. The filesystem is introduced in the first patch, and the
> subsequent patches make use of the filesystem interfaces, in drm driver,
> and making them available for use by the drm subsystem components, one of
> which is i915. We've moved the location of i915 GuC logs from debugfs to
> drmfs in the last patch. Subsequently, more such files such as pipe_crc,
> error states, memory stats, etc. can be move to this filesystem, if the
> idea introduced here is acceptable per se. The filesystem introduced is
> being used to house the data generated by i915 driver in this patch series,
> but will hopefully be generic enough to provide scope for usage by any
> other drm subsystem component.
> 
> The patch series is being floated as RFC to gather feedback on the idea and
> infrastructure proposed here and it's suitability to address the specific
> problem statement/use case.
> 
> v2: fix the bat failures caused due to missing config check
> 
> v3: Changes made:
> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
> - Moving config checks to header (Chris,Daniel)
> 
> v4: Added the kernel Documentaion (using Sphinx).
> 
> Sourab Gupta (4):
>   drm: Introduce drmfs pseudo filesystem interfaces
>   drm: Register drmfs filesystem from drm init
>   drm: Create driver specific root directory inside drmfs
>   drm/i915: Creating guc log file in drmfs instead of debugfs
> 
>  Documentation/gpu/drm-uapi.rst |  76 
>  drivers/gpu/drm/Kconfig|   9 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/drm_drv.c  |  26 ++
>  drivers/gpu/drm/drmfs.c| 566 ++
>  drivers/gpu/drm/i915/i915_guc_submission.c |  33 +-
>  include/drm/drm_drv.h  |   3 +
>  include/drm/drmfs.h|  77 
>  include/uapi/linux/magic.h |   3 +
>  9 files changed, 773 insertions(+), 21 deletions(-)
>  create mode 100644 drivers/gpu/drm/drmfs.c
>  create mode 100644 include/drm/drmfs.h

-- 
Regards,

Laurent Pinchart

[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[swati.dhin...@intel.com]

From: Swati Dhingra 

Currently, we don't have a stable ABI which can be used for the purpose of
providing output debug/loggging/crc and other such data from DRM.
The ABI in current use (filesystems, ioctls, et al.) have their own
constraints and are intended to output a particular type of data.
Few cases in point:
sysfs   - stable ABI, but constrained to one textual value per file
debugfs - unstable ABI, free-for-all
ioctls  - not as suitable to many single purpose continuous data
  dumping, we would very quickly run out ioctl space; requires more
  userspace support than "cat"
device nodes -  a real possibilty, kernel instantiation is more tricky,
requires udev (+udev.rules) or userspace discovery of the
dynamic major:minor (via sysfs) [mounting a registered
filesystem is easy in comparison]
netlink - stream based, therefore involves numerous copies.

Debugfs is the lesser among the evils here, thereby we have grown used to the
convenience and flexibility in presentation that debugfs gives us
(including relayfs inodes) that we want some of that hierachy in stable user
ABI form.

Due to these limitations, there is a need for a new pseudo filesytem, that
would act as a stable 'free-for-all' ABI, with the heirarchial structure and
thus convenience of debugfs. This will be managed by drm, thus named 'drmfs'.
DRM would register this filesystem to manage a canonical mountpoint, but this
wouldn't limit everyone to only using that pseudofs underneath.

This can serve to hold various kinds of output data from Linux DRM subsystems,
for the files which can't truely fit anywhere else with existing ABI's but
present so, for the lack of a better place.

In this patch series, we have introduced a pseudo filesystem named as 'drmfs'
for now. The filesystem is introduced in the first patch, and the subsequent
patches make use of the filesystem interfaces, in drm driver, and making them
available for use by the drm subsystem components, one of which is i915.
We've moved the location of i915 GuC logs from debugfs to drmfs in the last
patch. Subsequently, more such files such as pipe_crc, error states, memory
stats, etc. can be move to this filesystem, if the idea introduced here is
acceptable per se. The filesystem introduced is being used to house the data
generated by i915 driver in this patch series, but will hopefully be generic
enough to provide scope for usage by any other drm subsystem component.

The patch series is being floated as RFC to gather feedback on the idea and
infrastructure proposed here and it's suitability to address the specific
problem statement/use case.

v2: fix the bat failures caused due to missing config check

v3: Changes made:
- Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
- Moving config checks to header (Chris,Daniel)

v4: Added the kernel Documentaion (using Sphinx).

Sourab Gupta (4):
  drm: Introduce drmfs pseudo filesystem interfaces
  drm: Register drmfs filesystem from drm init
  drm: Create driver specific root directory inside drmfs
  drm/i915: Creating guc log file in drmfs instead of debugfs

 Documentation/gpu/drm-uapi.rst |  76 
 drivers/gpu/drm/Kconfig|   9 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/drm_drv.c  |  26 ++
 drivers/gpu/drm/drmfs.c| 566 +
 drivers/gpu/drm/i915/i915_guc_submission.c |  33 +-
 include/drm/drm_drv.h  |   3 +
 include/drm/drmfs.h|  77 
 include/uapi/linux/magic.h |   3 +
 9 files changed, 773 insertions(+), 21 deletions(-)
 create mode 100644 drivers/gpu/drm/drmfs.c
 create mode 100644 include/drm/drmfs.h

-- 
2.7.4

[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[sourab gupta]

On Mon, 2016-12-12 at 07:33 -0800, Alex Deucher wrote:
> On Mon, Dec 12, 2016 at 1:14 AM, sourab gupta  
> wrote:
> > On Mon, 2016-12-05 at 03:06 -0800, Dhingra, Swati wrote:
> >> From: Swati Dhingra 
> >>
> >> Currently, we don't have a stable ABI which can be used for the purpose of
> >> providing output debug/loggging/crc and other such data from DRM.
> >> The ABI in current use (filesystems, ioctls, et al.) have their own
> >> constraints and are intended to output a particular type of data.
> >> Few cases in point:
> >> sysfs   - stable ABI, but constrained to one textual value per file
> >> debugfs - unstable ABI, free-for-all
> >> ioctls  - not as suitable to many single purpose continuous data
> >>   dumping, we would very quickly run out ioctl space; requires more
> >>   userspace support than "cat"
> >> device nodes -  a real possibilty, kernel instantiation is more tricky,
> >> requires udev (+udev.rules) or userspace discovery of the
> >> dynamic major:minor (via sysfs) [mounting a registered
> >> filesystem is easy in comparison]
> >> netlink - stream based, therefore involves numerous copies.
> >>
> >> Debugfs is the lesser among the evils here, thereby we have grown used to 
> >> the
> >> convenience and flexibility in presentation that debugfs gives us
> >> (including relayfs inodes) that we want some of that hierachy in stable 
> >> user
> >> ABI form.
> >>
> >> Due to these limitations, there is a need for a new pseudo filesytem, that
> >> would act as a stable 'free-for-all' ABI, with the heirarchial structure 
> >> and
> >> thus convenience of debugfs. This will be managed by drm, thus named 
> >> 'drmfs'.
> >> DRM would register this filesystem to manage a canonical mountpoint, but 
> >> this
> >> wouldn't limit everyone to only using that pseudofs underneath.
> >>
> >> This can serve to hold various kinds of output data from Linux DRM 
> >> subsystems,
> >> for the files which can't truely fit anywhere else with existing ABI's but
> >> present so, for the lack of a better place.
> >>
> >> In this patch series, we have introduced a pseudo filesystem named as 
> >> 'drmfs'
> >> for now. The filesystem is introduced in the first patch, and the 
> >> subsequent
> >> patches make use of the filesystem interfaces, in drm driver, and making 
> >> them
> >> available for use by the drm subsystem components, one of which is i915.
> >> We've moved the location of i915 GuC logs from debugfs to drmfs in the last
> >> patch. Subsequently, more such files such as pipe_crc, error states, memory
> >> stats, etc. can be move to this filesystem, if the idea introduced here is
> >> acceptable per se. The filesystem introduced is being used to house the 
> >> data
> >> generated by i915 driver in this patch series, but will hopefully be 
> >> generic
> >> enough to provide scope for usage by any other drm subsystem component.
> >>
> >> The patch series is being floated as RFC to gather feedback on the idea and
> >> infrastructure proposed here and it's suitability to address the specific
> >> problem statement/use case.
> >>
> >> TODO: Create documentation. Will do so in next version.
> >>
> >> v2: fix the bat failures caused due to missing config check
> >>
> >> v3: Changes made:
> >> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
> >> - Moving config checks to header (Chris,Daniel)
> >>
> >>
> >> Sourab Gupta (4):
> >>   drm: Introduce drmfs pseudo filesystem interfaces
> >>   drm: Register drmfs filesystem from drm init
> >>   drm: Create driver specific root directory inside drmfs
> >>   drm/i915: Creating guc log file in drmfs instead of debugfs
> >>
> >>  drivers/gpu/drm/Kconfig|   9 +
> >>  drivers/gpu/drm/Makefile   |   1 +
> >>  drivers/gpu/drm/drm_drv.c  |  12 +
> >>  drivers/gpu/drm/drmfs.c| 555 
> >> +
> >>  drivers/gpu/drm/i915/i915_guc_submission.c |  33 +-
> >>  include/drm/drm_drv.h  |   3 +
> >>  include/drm/drmfs.h|  77 
> >>  include/uapi/linux/magic.h |   3 +
> >>  8 files changed, 672 insertions(+), 21 deletions(-)
> >>  create mode 100644 drivers/gpu/drm/drmfs.c
> >>  create mode 100644 include/drm/drmfs.h
> >>
> >> --
> >> 2.7.4
> >>
> >
> > Hi dri-devel folks,
> >
> > Any feedback on the proposed drmfs infrastructure being proposed here?
> 
> I haven't looked too closely, but so far we haven't run into anything
> that we haven't been able to support via some combination of sysfs and
> debugfs.
> 
> Alex

Hi Alex,

The intent here is to introduce a stable free-for-all ABI which has the
hierarchical structure and convenience of debugfs. One of the possible
candidate/usecase here is for holding the GuC (micro-controller) logs.
Currently, we're using relayfs to provide these logs to userspace.
Relayfs needs a parent dentry to be 

[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[sourab gupta]

On Mon, 2016-12-05 at 03:06 -0800, Dhingra, Swati wrote:
> From: Swati Dhingra 
> 
> Currently, we don't have a stable ABI which can be used for the purpose of
> providing output debug/loggging/crc and other such data from DRM.
> The ABI in current use (filesystems, ioctls, et al.) have their own
> constraints and are intended to output a particular type of data.
> Few cases in point:
> sysfs   - stable ABI, but constrained to one textual value per file
> debugfs - unstable ABI, free-for-all
> ioctls  - not as suitable to many single purpose continuous data
>   dumping, we would very quickly run out ioctl space; requires more
>   userspace support than "cat"
> device nodes -  a real possibilty, kernel instantiation is more tricky,
> requires udev (+udev.rules) or userspace discovery of the
> dynamic major:minor (via sysfs) [mounting a registered
> filesystem is easy in comparison]
> netlink - stream based, therefore involves numerous copies.
> 
> Debugfs is the lesser among the evils here, thereby we have grown used to the
> convenience and flexibility in presentation that debugfs gives us
> (including relayfs inodes) that we want some of that hierachy in stable user
> ABI form.
> 
> Due to these limitations, there is a need for a new pseudo filesytem, that
> would act as a stable 'free-for-all' ABI, with the heirarchial structure and
> thus convenience of debugfs. This will be managed by drm, thus named 'drmfs'.
> DRM would register this filesystem to manage a canonical mountpoint, but this
> wouldn't limit everyone to only using that pseudofs underneath.
> 
> This can serve to hold various kinds of output data from Linux DRM subsystems,
> for the files which can't truely fit anywhere else with existing ABI's but
> present so, for the lack of a better place.
> 
> In this patch series, we have introduced a pseudo filesystem named as 'drmfs'
> for now. The filesystem is introduced in the first patch, and the subsequent
> patches make use of the filesystem interfaces, in drm driver, and making them
> available for use by the drm subsystem components, one of which is i915.
> We've moved the location of i915 GuC logs from debugfs to drmfs in the last
> patch. Subsequently, more such files such as pipe_crc, error states, memory
> stats, etc. can be move to this filesystem, if the idea introduced here is
> acceptable per se. The filesystem introduced is being used to house the data
> generated by i915 driver in this patch series, but will hopefully be generic
> enough to provide scope for usage by any other drm subsystem component.
> 
> The patch series is being floated as RFC to gather feedback on the idea and
> infrastructure proposed here and it's suitability to address the specific
> problem statement/use case.
> 
> TODO: Create documentation. Will do so in next version.
> 
> v2: fix the bat failures caused due to missing config check
> 
> v3: Changes made:
> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
> - Moving config checks to header (Chris,Daniel)
> 
> 
> Sourab Gupta (4):
>   drm: Introduce drmfs pseudo filesystem interfaces
>   drm: Register drmfs filesystem from drm init
>   drm: Create driver specific root directory inside drmfs
>   drm/i915: Creating guc log file in drmfs instead of debugfs
> 
>  drivers/gpu/drm/Kconfig|   9 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/drm_drv.c  |  12 +
>  drivers/gpu/drm/drmfs.c| 555 
> +
>  drivers/gpu/drm/i915/i915_guc_submission.c |  33 +-
>  include/drm/drm_drv.h  |   3 +
>  include/drm/drmfs.h|  77 
>  include/uapi/linux/magic.h |   3 +
>  8 files changed, 672 insertions(+), 21 deletions(-)
>  create mode 100644 drivers/gpu/drm/drmfs.c
>  create mode 100644 include/drm/drmfs.h
> 
> --
> 2.7.4
> 

Hi dri-devel folks,

Any feedback on the proposed drmfs infrastructure being proposed here?

Regards,
Sourab

[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[Alex Deucher]

On Mon, Dec 12, 2016 at 1:14 AM, sourab gupta  wrote:
> On Mon, 2016-12-05 at 03:06 -0800, Dhingra, Swati wrote:
>> From: Swati Dhingra 
>>
>> Currently, we don't have a stable ABI which can be used for the purpose of
>> providing output debug/loggging/crc and other such data from DRM.
>> The ABI in current use (filesystems, ioctls, et al.) have their own
>> constraints and are intended to output a particular type of data.
>> Few cases in point:
>> sysfs   - stable ABI, but constrained to one textual value per file
>> debugfs - unstable ABI, free-for-all
>> ioctls  - not as suitable to many single purpose continuous data
>>   dumping, we would very quickly run out ioctl space; requires more
>>   userspace support than "cat"
>> device nodes -  a real possibilty, kernel instantiation is more tricky,
>> requires udev (+udev.rules) or userspace discovery of the
>> dynamic major:minor (via sysfs) [mounting a registered
>> filesystem is easy in comparison]
>> netlink - stream based, therefore involves numerous copies.
>>
>> Debugfs is the lesser among the evils here, thereby we have grown used to the
>> convenience and flexibility in presentation that debugfs gives us
>> (including relayfs inodes) that we want some of that hierachy in stable user
>> ABI form.
>>
>> Due to these limitations, there is a need for a new pseudo filesytem, that
>> would act as a stable 'free-for-all' ABI, with the heirarchial structure and
>> thus convenience of debugfs. This will be managed by drm, thus named 'drmfs'.
>> DRM would register this filesystem to manage a canonical mountpoint, but this
>> wouldn't limit everyone to only using that pseudofs underneath.
>>
>> This can serve to hold various kinds of output data from Linux DRM 
>> subsystems,
>> for the files which can't truely fit anywhere else with existing ABI's but
>> present so, for the lack of a better place.
>>
>> In this patch series, we have introduced a pseudo filesystem named as 'drmfs'
>> for now. The filesystem is introduced in the first patch, and the subsequent
>> patches make use of the filesystem interfaces, in drm driver, and making them
>> available for use by the drm subsystem components, one of which is i915.
>> We've moved the location of i915 GuC logs from debugfs to drmfs in the last
>> patch. Subsequently, more such files such as pipe_crc, error states, memory
>> stats, etc. can be move to this filesystem, if the idea introduced here is
>> acceptable per se. The filesystem introduced is being used to house the data
>> generated by i915 driver in this patch series, but will hopefully be generic
>> enough to provide scope for usage by any other drm subsystem component.
>>
>> The patch series is being floated as RFC to gather feedback on the idea and
>> infrastructure proposed here and it's suitability to address the specific
>> problem statement/use case.
>>
>> TODO: Create documentation. Will do so in next version.
>>
>> v2: fix the bat failures caused due to missing config check
>>
>> v3: Changes made:
>> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
>> - Moving config checks to header (Chris,Daniel)
>>
>>
>> Sourab Gupta (4):
>>   drm: Introduce drmfs pseudo filesystem interfaces
>>   drm: Register drmfs filesystem from drm init
>>   drm: Create driver specific root directory inside drmfs
>>   drm/i915: Creating guc log file in drmfs instead of debugfs
>>
>>  drivers/gpu/drm/Kconfig|   9 +
>>  drivers/gpu/drm/Makefile   |   1 +
>>  drivers/gpu/drm/drm_drv.c  |  12 +
>>  drivers/gpu/drm/drmfs.c| 555 
>> +
>>  drivers/gpu/drm/i915/i915_guc_submission.c |  33 +-
>>  include/drm/drm_drv.h  |   3 +
>>  include/drm/drmfs.h|  77 
>>  include/uapi/linux/magic.h |   3 +
>>  8 files changed, 672 insertions(+), 21 deletions(-)
>>  create mode 100644 drivers/gpu/drm/drmfs.c
>>  create mode 100644 include/drm/drmfs.h
>>
>> --
>> 2.7.4
>>
>
> Hi dri-devel folks,
>
> Any feedback on the proposed drmfs infrastructure being proposed here?

I haven't looked too closely, but so far we haven't run into anything
that we haven't been able to support via some combination of sysfs and
debugfs.

Alex

[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[swati.dhin...@intel.com]

From: Swati Dhingra 

Currently, we don't have a stable ABI which can be used for the purpose of
providing output debug/loggging/crc and other such data from DRM.
The ABI in current use (filesystems, ioctls, et al.) have their own
constraints and are intended to output a particular type of data.
Few cases in point:
sysfs   - stable ABI, but constrained to one textual value per file
debugfs - unstable ABI, free-for-all
ioctls  - not as suitable to many single purpose continuous data
  dumping, we would very quickly run out ioctl space; requires more
  userspace support than "cat"
device nodes -  a real possibilty, kernel instantiation is more tricky,
requires udev (+udev.rules) or userspace discovery of the
dynamic major:minor (via sysfs) [mounting a registered
filesystem is easy in comparison]
netlink - stream based, therefore involves numerous copies.

Debugfs is the lesser among the evils here, thereby we have grown used to the
convenience and flexibility in presentation that debugfs gives us
(including relayfs inodes) that we want some of that hierachy in stable user
ABI form.

Due to these limitations, there is a need for a new pseudo filesytem, that
would act as a stable 'free-for-all' ABI, with the heirarchial structure and
thus convenience of debugfs. This will be managed by drm, thus named 'drmfs'.
DRM would register this filesystem to manage a canonical mountpoint, but this
wouldn't limit everyone to only using that pseudofs underneath.

This can serve to hold various kinds of output data from Linux DRM subsystems,
for the files which can't truely fit anywhere else with existing ABI's but
present so, for the lack of a better place.

In this patch series, we have introduced a pseudo filesystem named as 'drmfs'
for now. The filesystem is introduced in the first patch, and the subsequent
patches make use of the filesystem interfaces, in drm driver, and making them
available for use by the drm subsystem components, one of which is i915.
We've moved the location of i915 GuC logs from debugfs to drmfs in the last
patch. Subsequently, more such files such as pipe_crc, error states, memory
stats, etc. can be move to this filesystem, if the idea introduced here is
acceptable per se. The filesystem introduced is being used to house the data
generated by i915 driver in this patch series, but will hopefully be generic
enough to provide scope for usage by any other drm subsystem component.

The patch series is being floated as RFC to gather feedback on the idea and
infrastructure proposed here and it's suitability to address the specific
problem statement/use case.

TODO: Create documentation. Will do so in next version.

v2: fix the bat failures caused due to missing config check

v3: Changes made:
- Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
- Moving config checks to header (Chris,Daniel)


Sourab Gupta (4):
  drm: Introduce drmfs pseudo filesystem interfaces
  drm: Register drmfs filesystem from drm init
  drm: Create driver specific root directory inside drmfs
  drm/i915: Creating guc log file in drmfs instead of debugfs

 drivers/gpu/drm/Kconfig|   9 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/drm_drv.c  |  12 +
 drivers/gpu/drm/drmfs.c| 555 +
 drivers/gpu/drm/i915/i915_guc_submission.c |  33 +-
 include/drm/drm_drv.h  |   3 +
 include/drm/drmfs.h|  77 
 include/uapi/linux/magic.h |   3 +
 8 files changed, 672 insertions(+), 21 deletions(-)
 create mode 100644 drivers/gpu/drm/drmfs.c
 create mode 100644 include/drm/drmfs.h

-- 
2.7.4