Re: [PATCH 03/51] drm: add managed resources tied to drm_device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Daniel / Jani.

> On Mon, Mar 02, 2020 at 11:22:34AM +0200, Jani Nikula wrote:
> > On Sat, 29 Feb 2020, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote:
> > > On Sat, Feb 29, 2020 at 12:17 PM Sam Ravnborg <sam@xxxxxxxxxxxx> wrote:
> > >> The header-check infrastructure was dropped again - see:
> > >> fcbb8461fd2376ba3782b5b8bd440c929b8e4980
> > >
> > > Uh I'm disappoint :-/
> > 
> > To say the least. I thought it was a good *opt-in* feature for whoever
> > wanted it. But the part that got the backlash was applying it to
> > absolutely everything under include/. And then it got removed
> > altogether. From one extreme to the other. Nuts.
> > 
> > > Adding Jani in case he missed this too. I guess maybe we should
> > > resurrect it for drm again (and with a file pattern starting in a
> > > .dot).
> > 
> > We have a local implementation in i915/Makefile again. It uses 'find' to
> > find the headers which is fine in i915, but the parameters need to be
> > adjusted for drm to not be recursive. -maxdepth 1 or something. Also
> > need to add another local config option. Sad trombone.
> 
> Splitting this up into two threads.
> 
> Could we extend this to drm headers again too? Sad thrombones indeed, but
> at least here we could still the proper fanfares ... Maybe something like
> have the Makefile snippet in drivers/gpu and then keep a list of
> directories (or file glob patterns probably better) in there that it
> should check.
> 
> I really liked this entire idea very much.
> 
> Oh also maybe switch the temp files over to dotfiles, so Linus doesn't get
> upset (which really I think is all  that Linus expected, but I guess
> people just panic and revert).

I will try to give it a spin by adding the feature back to kbuild,
but without the excessive use.
And with dot-files so the run does not disturb.
So we avoid different sub-systemes makes there own small solutions.

Give me a few weeks - need to land some exciting (not) binding
patches for panel/ first.
Anyone else up to the task, then I will be happy to review.

	Sam
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux