On 2006.05.12 14:23:07 -0700, Garrett D'Amore wrote:
> After browsing, I notice that we are out of ioctl numbers for
> wsdisplay.  Basically, wscons allocates ioctl codes 64-95 to wsdisplay. 
> They are all used up.
> 
> I want to add more ioctls.  E.g. ioctls for changing screen resolution,
> and some kind of ioctls for accleration.
> 
> I notice that ioctls are allocated in a fashion that I *think* is
> wasteful.  As an example:
> 
> /* Cursor control: get and set position */
> #define    WSDISPLAYIO_GCURPOS    _IOR('W', 70, struct wsdisplay_curpos)
> #define    WSDISPLAYIO_SCURPOS    _IOW('W', 71, struct wsdisplay_curpos)
> 
> 
> These use two different values (70 & 71).  It strikes me that the _IOR
> and _IOW macros add other bits, and that maybe it could have been
> possible to make them both use 70 (as an example).
> 
> Colormaps, video settings, and others have this property as well.
> 
> There are a couple of ioctls which are recently used for splash screen
> support (SSPLASH and SPROGRESS).  Apart from these, I *think* all the
> values have "escaped" into the field, and cannot easily be reclaimed
> without breaking some applications.  (Though I think the number of
> applications in the field which actually use wsdisplay ioctls is
> probably quite small.)

I'm not replying to your questions, sorry. Since this will get more problematic
in the future, shouldn't we start thinking about a policy for ioctl
allocation?

<rant>
And, forgive me to say, ioctls are showing their age. Maybe we should
start wondering how we can replace them and be binary compatible if that's
possible.
sysctl is a nice interface for non-dynamic fields, but doesn't solve
the issue for dynamic objects.

There's a paper about this issue by phk@FreeBSD:
http://www.bsdcan.org/2005/papers/bsdcan2005_ioctl.pdf
Most likely, a lot of people already read it.
</rant>

P.S.: Please don't interpret this as a bikeshed. I'm only trying to gather
ideas..

-- 
  Rui Paulo			<rpaulo@{NetBSD{,-PT}.org,fnop.net}>