> > I honestly don't see a problem with having multiple memory managers. We > have different hardware with different functionality and different > performance characteristics. The probability of one memory manager > fitting everywhere is nil. Quite frankly, the fact that it has take > this long to get *anything* upstream is already failure. > > This is open source. Release early, release often. If something gets > implemented and doesn't work out, you redo it. You don't spend forever > trying to get it perfect before you release anything. :(
I didn't want one memory manager,as much as I wanted one common API for a memory manager, with driver specific functions ala superioctl. Ideally this meant a buffer object and a fence meant and operated the same way to everyone... so that writing drivers was at least using the same naming etc.. and that userspace API was supportable. I quite understood that underneath may end up with just ioctl into driver back into common code or into driver specifc code for some cases and this is fine, but I believe the API to userspace to create and manipulate objects should be common and sane. Ian, quoting open-source mantras may work in some places, but you really need to understand you cannot upstream unsupportable kernel APIs, and drop them alter. I still maintain the internals of the drm to support i810 and i830 drivers. I can probably drop them in 5-10 years maybe. Userspace APIs cannot die once released, so in this case release early and often doesn't apply. There are many kernel mailing list and lwn articles on this topic if you'd like to get past the mantra... Dave. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
