> Wed, Mar 05, 2003 at 12:23:50AM +0000, Alan Cox wrote: > > "It works" is not the same as "it works cleanly". > > APIs should be fixed, concrete definitions. The struct definitions in drm.h > > are essentially part of the API (or ABI, whatever), and they are not fixed. > > They should be cleaned up. > > You can never achieve that on a wide cross platform OS. Little things like > struct padding, alignment rules and so on get in the way now and then. There > is an additional consideration because x86 is -horrible- at 64bit ops, gcc > manages to do it quite badly at times too making it even uglier.
I dont see what performance has to do with informational type fields being passed through an ioctl struct. > Either way having typedefs for these so they can stay unsigned long and > munged on x86 versus enforced 64bit on solaris doesn't seem to cause any > problems. Yeah, it would solve my problem, so I wont argue too hard if you want to just go ahead and do that. But there could be a ludicrous amount of extra typedefs for this sort of thing if you dont draw the line somewhere. For basic non-pointer-involved types, I would think everyone would benefit, and you probably would not break anything, if you specified [u]intXX_t types for all the structs that currently have the more loose declarations. Well, okay, let me clarify that prior point, I suppose. You wont break source compatibility. If you take machine type X, compile a fresh driver and x server and client libs from new source, it should all still work if you changed everything in drm.h to used fixed size info. If you took a preexisting machine, with an older drm kernel driver, and tried to use the new source on it, it would break. But then, that happens now anyway after DRI upgrades, doesnt it, so I dont see that this should be considered a big deal.... > For some of the DRM API's I'd agree with you - they don't hit the > performance considerations. However we already have an API and most > XFree86 4.1/4.2/4.3 drivers [1] all run with the 4.3 DRM. You'd break that > by changing the types. > > [1] i810 breaks 44.1 to 4.2 and 4.2 to 4.3 8( There have been NO new card-specific ioctls added since xfree4.1, apart from I810 ? I'm surprised. But, reguardless... I'd say migrating to a cleaner data structure that can then remain fixed for longer, is good justification for doing a one-time breakage upgrade. If you dont want to, that's your call. But it's the "Right Thing To Do", IMO. ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
