Re: DRM code reorganization

[Dave Airlie]

>
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/