Am 17.02.23 um 12:36 schrieb Stanislaw Gruszka:
On Fri, Feb 17, 2023 at 12:49:41PM +0200, Jani Nikula wrote:
On Fri, 17 Feb 2023, Stanislaw Gruszka <stanislaw.gruszka@xxxxxxxxxxxxxxx> wrote:
On Thu, Feb 16, 2023 at 07:06:46PM +0200, Jani Nikula wrote:
But should not this the driver responsibility, call drm_debugfs_add_file()
whenever you are ready to handle operations on added file ?
In theory, yes, but in practice it's pretty hard for a non-trivial
driver to maintain that all the conditions are met.
Hmmm...
In i915 we call debugfs register all over the place only after we've
called drm_dev_register(), because it's the only sane way. But it means
we need the init and register separated everywhere, instead of init
adding files to a list to be registered later.
Isn't this done this way in i915 only because it was not possible
(and still isn't) to call drm_debugfs_create_file() before registration ?
I think it's should be ok by i915 subsystem to create it's debugfs
files and allow to access to them just after that subsystem init.
Or there are some complex dependencies between i915 subsystems,
that reading registers from one subsystem will corrupt some
other subsystem that did non finish initialization yet?
That's the point. It's really hard to figure it all out. Why bother?
I see.
Just hope we could get something simpler to limit debugfs access
before registration: unix hidden file, permissions or other way.
Because current drm_debufs_add_file() implementation looks
really over convoluted to me.
Completely agree.
We have intentionally removed exactly that approach from radeon because
it just lead to and over all bad driver design and more problems than it
solved.
If i915 have such structural problems then I strongly suggest to solve
them inside i915 and not make common code out of that. This just
encourages others to follow that lead.
Regards,
Christian.
Regards
Stanislaw
