Re: New DRM driver model - gets rid of DRM() macros!
From: Dave Airlie (airlied_at_gmail.com)
Date: Wed, 29 Sep 2004 23:41:16 +1000 To: Christoph Hellwig <email@example.com>, Jon Smirl <firstname.lastname@example.org>, dri-devel <email@example.com>, Xserver development <firstname.lastname@example.org>, lkml <email@example.com>
> - once we have Alan's idea of the graphics core implemented drm_init()
> should go awaw
> - drm_probe (and it's call to drm_fill_in_dev) looks a little fishy,
> what about doing the full ->probe callback in each driver where it
> can do basic hw setup, dealing with pci and calls back into the drm
> core for minor number allocation and common structure allocations.
We have mentioned this but 90% of the work done by the drivers would
be common, we might do it the otherway I suppose have a driver probe
that calls a function in the core,
> This would get rid of the ->preinit and ->postinit hooks.
> - isn't drm_order just a copy of get_order()?
> - any chance to use proper kernel-doc comments instead of the bastdized
> and hard to read version you have currently?
I think we have doxygen comments in there at the moment - the Mesa/DRI
documentation is done with doxygen...
> - the coding style is a little strange, like spurious whitespaces inside
> braces, maybe you could run it through scripts/Lindent
there are a fair few of these in there in the kernel, it could
probably do with a Lindent at some stage over the whole thing...
> - care to use linux/lists.h instead of opencoded lists, e.g. in
> dev->file_last/dev->file_first or dev->vmalist
> - drm_flush is a noop. a NULL ->flush does the same thing, just easier
> - dito or ->poll
> - dito for ->read
> - why do you use DRM_COPY_FROM_USER_IOCTL in Linux-specific code?
> - drm__mem_info should be converted to fs/seq_file.c functions
> - dito for functions in drm_proc.c
I think I can apply a lot of these to the current kernel code so I'll
probably just start doing patches up for these sort of issues
I'll get time to create a bitkeeper tree taking Jons changes ready for
merging to Andrew at least, and maybe Linus for 2.6.10.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/