On Aug 22, 07 17:21:09 +0300, Daniel Stone wrote:
> > But that exactly makes version control difficult (lots of cases,
> > especially if the exact requirements aren't clear from day one).
> 
> I honestly don't understand the problem.  Your ioctl number is _that_
> request.  It's not referring to a vague concept, but a single structure
> you've already specified.

Well, you already know what parameters you need for selecting
crtcs/outputs/modes/etc.? I would assume that the needed parameters will
change over time, as new features are thought of etc. And I could
imagine that this happens frequently.

> If you have ioctl number 32, your next free one is 43, and you want to
> change the semantics of UPDATE_WINDOW, then you rename 32 to
> UPDATE_WINDOW_OLD, create UPDATE_WINDOW as 43 with the new structure,
> and handle both cases.

I consider this giving headaches.
I never had any similar issues with a tag-based approach.

Well, it's not my baby, I won't cry ;-)
Just trying to give some help.

> > Without a version field, this is made impossible, something that must be
> > avoided at all costs.
> 
> Except that your ioctl then becomes variably-sized unless you add loads
> of padding and hope for the best.

If every tag is int32 and its parameter int32 as well, this isn't too
problematic. Question is whether everything needed can be represented in
32 bit values, strings are a completely different concept and don't
match well here, as pointers are probably difficult to handle over the
user land / kernel barrier...

CU

Matthias

-- 
Matthias Hopf <[EMAIL PROTECTED]>      __        __   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          [EMAIL PROTECTED]
Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to