Subject: Re: wsdisplay ioctls
To: Garrett D'Amore <>
From: Rui Paulo <>
List: tech-kern
Date: 05/13/2006 00:29:07
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

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
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:
Most likely, a lot of people already read it.

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

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