Messages in this thread | | | Date | Tue, 3 Aug 2004 01:06:44 +0100 (IST) | From | Dave Airlie <> | Subject | Re: DRM code reorganization |
| |
> > How does this differ from any other subsystem that supports > cards with features that may not be present in another model ? > Other subsystems have dealt with this problem without the need > to introduce horrors like the abstractions in DRM.
The biggest issue I have with all the other subsystems that do this, is the re-writing of basic driver code *for every driver*, everyone has a PCI table, with a routine called my_driver_probe, and my_driver_init and my_driver_exit and when you start a new driver you have to go all cut-and-paste on its ass, someone changes and interface, you've got to go change 20 files...
The DRM doesn't suffer from this, we've made huge changes to the DRM pci probing code for *all* drivers (it's in the -mm tree if you want to look) by changing one file, I'd hate to see similiar work being done to the fb tree, you'd be cut-n-pasting and changing names of functions and it would be horrible drudge work, the DRM isn't a maintainers paradise but if you learn how it works it is an awful lot easier to maintain than similiar subsystems...
> And among other horrors, crap like typedef's that magically change their > type completely depending on which file they are #include'd into. > Overuse of typedefs is one thing, but what goes on with stuff like > DRIVER_BUF_PRIV_T is bordering on obscene. >
this sort of stuff could probably be cleaned up, I'm not so sure this re-org everyone is pushing for isn't going to lead to people wishing it was the old way again :-)
> >From the view of many kernel developers, anything would be > better than the trainwreck of wrappers/macros/preprocessor abuse > that's there right now. I'd put money on a lot more people being > prepared to hack on DRM's kernel code if it were more readable. >
If we start putting fb type functionality into it more people will start coming towards it alright... it would be nice if it was a bit more homely..
I'm sitting on the fence at the moment, as I'm not going to be able to contribute the amount of time for a big re-write I'm willing to help out with small changes and keep track of what patches go where....
Dave.
-- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |