[PATCH 0/7] drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input

[Daniel Vetter]

On Wed, Nov 05, 2014 at 02:24:42PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 05, 2014 at 02:25:12PM +0100, Thierry Reding wrote:
> > Discussion on IRC lead to the conclusion that new IOCTLs should have
> > input validation and require userspace to zero out output parameters to
> > avoid this kind of mess in the future. In order to help avoid this kind
> > of ambiguity it would be a good idea to start documenting IOCTLs more
> > officially (e.g. in the DRM DocBook).
> 
> That is a good point, however not everyone can build the documentation.
> I tried a while back and the whole documentation subsystem is /soo/
> fragile its untrue.  You have to have the exact right versions installed
> and hope that the exact right versions have configured themselves to
> work together correctly, otherwise you get cryptic unsolvable error
> messages.  Tex is notorious for these problems.
> 
> When I tried to generate the docbook stuff, after spending a significant
> amount of time trying to debug it, I just gave up completely with any
> ideas about ever adding to the documentation.  I've since decided that
> I am /never/ going to do anything past adding docbook comments to files.
> 
> If someone cares about linking them into the rest of the docbook system,
> and they have the capability to generate the docbook output, then that's
> fine and dandy, but I believe that requiring everyone to have that
> capability is asking far too much.

Ime all the kerneldoc and tex stuff is hopeless. The only thing I use is

$ make htmldocs

That works somewhat after a bit of wrestling. But note that it doesn't
handle file renames gracefully and make clean won't get you out of that
fuzz. So my build-docs script also has a

$ git clean -dfx Documentation/DocBook

in there. Not pretty I agree. Add to that that kerneldoc is a feature poor
markup language (no lists, hyperlinks, chapters or anything really).

I'm trying really hard to get someone at intel (or paid by intel) to fix
this mess up though.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch