Date: Sun, 28 Nov 2004 11:08:38 +0100 (MET)
From: Jan Engelhardt <jengelh@linux01.gwdg.de>
To: Miklos Szeredi <miklos@szeredi.hu>
cc: viro@parcelfarce.linux.theplanet.co.uk, oebilgen@uekae.tubitak.gov.tr,
       linux-kernel@vger.kernel.org
Subject: Re: Problem with ioctl command TCGETS
In-Reply-To: <E1CYLpf-0001VQ-00@dorka.pomaz.szeredi.hu>
Message-ID: <Pine.LNX.4.53.0411281104100.20168@yvahk01.tjqt.qr>
References: <20041128002044.CE13839877@uekae.uekae.gov.tr>
 <20041128003901.GS26051@parcelfarce.linux.theplanet.co.uk>
 <E1CYLpf-0001VQ-00@dorka.pomaz.szeredi.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1254
Lines: 35

>On the subject of ioctls:  what about a replacement syscall:
>
> /**
>  * Getting and setting file parameters safely (ioctl done right)
>  *
>  * @fd     file descriptor
>  * @param  name of the parameter to get/set
>  * @dir    direction flag indicating either get, set, or set-get
>  * @value  value to set parameter to (set) or store current value into (get)
>  * @size   size of value
>  */
> int fparam(int fd, const char *param, int dir, void *value, size_t size);
>
>I know it's been talked about in the past.  Is anyone interested?

The idea is nice, yet the "dir" and "size" parameters in the original _IO*
macros are only there (IMO) to protect against using the wrong value for the
wrong operation on the wrong fd/file/device/socket/etc.

What is the point in making "param" a char*? You would need to parse it down
again.

Oh yeah and call it ioctl2(), sounds more cryptical :)


Jan Engelhardt
-- 
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/