Quoting Balestrieri, Francesco (2019-09-11 13:03:25) > On 04/09/2019, 13.33, "Intel-gfx on behalf of Daniel Vetter" <intel-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx on behalf of daniel@xxxxxxxx> wrote: > > On Mon, Aug 26, 2019 at 2:21 PM Abdiel Janulgue > > - ret = create_mmap_offset(obj); > > - if (ret == 0) > > - *offset = drm_vma_node_offset_addr(&obj->base.vma_node); > > + mmo = kzalloc(sizeof(*mmo), GFP_KERNEL); > > I got thrown off a bunch of times here reading the code, but I think I > got this right now. > > Why exactly do we want multiple vma offsets? Yes this makes it a > drop-in replacement for the old cpu mmap ioctl, which was a bit > dubious design. But if we go all new here, I really wonder about why > this is necessary. No other discrete driver needs this, they all fix > the mmap mode for the lifetime of an object, because flushing stuff is > as expensive as just reallocating (or at least close enough). > > I think us going once again our separate route here needs a lot more > justification than just "we've accidentally ended up with uapi like > this 10 years ago". That's exactly the whole point, to replace the uapi we accidentally ended up with 10 years ago with the api that doesn't cause valgrind to complain, is easily extensible and supports all legacy usecases which should be a very good position to be in to support unknown future usecases as well. Letting userspace control their mmapings is very powerful, and we definitely do not want to be limiting their flexibility. That no other driver even seems to allow multiple mmaps, and so has not developed a desire to manage multiple vma per object does not seem to be a reason to limit ourselves. The infrastructure all supports it; the only thing that is at odds is the desire to force the lowest common denominator as the defacto standard. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
