On Thu, Apr 27, 2017 at 10:58:42AM -0700, Lionel Landwerlin wrote: > On 27/04/17 08:20, Eric Anholt wrote: > > Emil Velikov <emil.l.veli...@gmail.com> writes: > > > > > On 25 April 2017 at 23:56, Lionel Landwerlin > > > <lionel.g.landwer...@intel.com> wrote: > > > > Hi, > > > > > > > > While working with changes that span from kernel to user space, I've > > > > been wondering whether we need to depend on libdrm at all for the anv > > > > & i965 drivers. Indeed with Ken's recent changes, we only depend on > > > > libdrm for its kernel header files which we could just embed > > > > ourselves. > > > > > > > > I've only included the minimal set of header files we need from the > > > > kernel for anv & i965. Maybe other drivers would be interested and > > > > maybe we should put all the kernel drm uapi headers into include? > > > > > > > AFAICT the goal behind the libdrm_intel fold was to allow rapid and > > > seamless rework of the interface. > > > With a potential goal to make it a shared one, as it gets stabilised. > > > > > > Currently ANV uses more than just the UAPI headers. But if we ignore > > > that, coping them is a bad idea. > > What else is anv using from libdrm? (maybe I missed something) > > > > > > > Why - adds a, yet another, copy and making synchronisation more > > > annoying. First example - you blindly copied the files rather than > > > using `make headers_install' first ;-) > > > Not to mention that it makes the chicken and egg problem* even more > > > confusing and error prone. > > It doesn't feel like that to me. Actually instead of modifying 3 different > repos, you end up modifying just 2. > Sounds less error prone. > > > > > > > Emil > > > * Which patches land first - kernel or userspace > > I don't see how it does that at all. It simplifies the process: Now you > > send out your proposed new userspace to one repo, instead of two. > > > > And, after the first commit, it'll be obvious when you screw up using > > make headers_install because there will be surprising diff. > > Right now we have to update libdrm, then update the mesa to depend on the > right libdrm to actually get the header files we want. > If you depend on libdrm from more than just uapi headers, it might now be > too much of a burden. But it seems we're clearly moving away from that in > anv/i965. > As a developer it feels a lot easier to have just the update mesa with both > the new kernel API you depend on & the changes to the user space driver > using that API.
As long as the headers are never installed into the system I'm in principle ok with pulling all the i915.ko specific stuff into mesa. Seems like a reasonable thing to do. Of course still the same rules apply for merging new uapi: All parts must be reviewed, then we merge the kernel, and only afterwards userspace. The headers process in libdrm (see libdrm/include/drm/README) is imo the best model for that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
