Paul Mackerras writes: > Egbert Eich writes: > > > Non of the patches that I've posted had problems with backward > > compatibility. > > At least not across the kernel/user space interface. > > Originally I had one that wasn't however that had been fixed before > > I put patches into the fd.o bugzilla. > > No, your patches originally changed the size of the drm_map_t, and > added a drm32_map_t which was a different size from the old 32-bit
So you didn't notice that I've added backward compatibility functions so that the old call would still have worked. Since the size of the structure was different that was easy to do. > drm_map_t. That and the fact that I found your patch impossible to > follow was why I did my version. ... and reinvented the weel repeating the same errors that I have already been thru. Maybe you should have gotten in touch with me and we could have worked out something. > > Now you have a kernel drm_map_t which is different from the user > drm_map_t. I think this has the potential to be immensely confusing > to people. If the kernel needs an internal data structure to keep > information about maps, that's fine, but it should have a different > name. > Fine. I had a different version where I changed the name. Then kernel people told me it was too intrusive since I had to change the name at every occurance. This is why I came up with the drm_pub_map hack. It's really difficult to make it right for everyone in the kernel. Egbert. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
