Date: Mon, 14 Jun 2004 15:54:38 -0700
From: Tim Hockin <thockin@hockin.org>
To: Chris Friesen <cfriesen@nortelnetworks.com>
Cc: Bernd Petrovitsch <bernd@firmix.at>, Oliver Neukum <oliver@neukum.org>,
       Steve French <smfltc@us.ibm.com>, linux-kernel@vger.kernel.org
Subject: Re: upcalls from kernel code to user space daemons
Message-ID: <20040614225438.GA22161@hockin.org>
References: <1087250925.8828.3.camel@gimli.at.home> <40CE2538.4060603@nortelnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40CE2538.4060603@nortelnetworks.com>
User-Agent: Mutt/1.4.2i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 905
Lines: 22

On Mon, Jun 14, 2004 at 06:22:48PM -0400, Chris Friesen wrote:
> > > Not quite.  The userspace is passing data down as well.  I don't know 
> >how you'd
> > > do that with read().
> >
> >For this you use write().

> Although I have to admit it's not pretty, and the performance improvements 
> may not be worth the obfuscation of the code.

You know, I've never understood why people hate ioctl.  Sometimes, it
really is what you want.  Why impose structured data onto a 2-way
unstructred system (read/write) when you have a structured system at hand
(ioctl).

I like ioctl() when it makes sense.  read() and write() are for data.
ioctl is for (tada!) control.
-
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/