Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261453AbUK1MgX (ORCPT ); Sun, 28 Nov 2004 07:36:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261456AbUK1MgW (ORCPT ); Sun, 28 Nov 2004 07:36:22 -0500 Received: from rev.193.226.233.139.euroweb.hu ([193.226.233.139]:36834 "EHLO dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP id S261453AbUK1MgV (ORCPT ); Sun, 28 Nov 2004 07:36:21 -0500 To: viro@parcelfarce.linux.theplanet.co.uk CC: ecki-news2004-05@lina.inka.de, linux-kernel@vger.kernel.org In-reply-to: <20041128121800.GZ26051@parcelfarce.linux.theplanet.co.uk> (message from Al Viro on Sun, 28 Nov 2004 12:18:00 +0000) Subject: Re: Problem with ioctl command TCGETS References: <20041128121800.GZ26051@parcelfarce.linux.theplanet.co.uk> Message-Id: From: Miklos Szeredi Date: Sun, 28 Nov 2004 13:32:17 +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 716 Lines: 17 > Think read(2)/write(2). We already have several barfbags too many, > and that includes both ioctl() and setsockopt(). We are stuck with > them for compatibility reasons, but why the hell would we need yet > another one? You can't replace either ioctl() or setsockopt() with read/write can you? Both of them set out-of-band information on file descriptors. Proc maybe ('/proc/PID/fdparam/FD/param')? I'm sure some people would have objections to that too. Miklos - 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/