All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Joe Thornber <joe@fib011235813.fsnet.co.uk>
Cc: Linux Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@transmeta.com>,
	Dave Jones <davej@suse.de>
Subject: Re: [PATCH] Device-mapper submission 6/7
Date: Wed, 16 Oct 2002 10:20:30 -0400	[thread overview]
Message-ID: <3DAD75AE.7010405@pobox.com> (raw)
In-Reply-To: 20021015214420.GA28738@fib011235813.fsnet.co.uk

Joe Thornber wrote:
> On Tue, Oct 15, 2002 at 02:15:35PM -0400, Jeff Garzik wrote:
> 
>>>[Device mapper]
>>>Provide a traditional ioctl based interface to control device-mapper
>>
>>>from userland.
>>
>>
>>If you're adding a new interface, there should be no need to add new
>>ioctls and all that they entail.  Just control via a ramfs-based fs...
> 
> 
> We originally did have a fs based interface written by Steve
> Whitehouse.  However at the time (about a year ago) it wasn't obvious
> that everyone would think it a good idea.  Also the code was
> significantly larger than the ioctl interface.  I would be more than
> happy to do away with the ioctl stuff if people are now in full
> agreement that an fs interface is the way to go.


Which people didn't like it?  ;-)

AFAIK Linus and Al Viro (and myself <g>) have always considered ioctls 
an ugly -ism that should have never made it into Unix.  Over and above 
the Unix/VFS design problems with ioctl(2), ioctl(2) is a pain for 
people like David Miller who must maintain 32<->64 bit ioctl translation 
layers for their architecture.  ia64 and x64-64 must do this too.  Each 
ioctl you add is an additional headache for them.

We now have libfs.c in 2.5.x that makes ramfs-based filesystems even 
more tiny, too.  With the added flexibility of an fs -- it makes the 
userland tools much more simple and sane -- and the pain of ioctls, it 
seems a clear choice for new interfaces.

	Jeff




  reply	other threads:[~2002-10-16 14:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-15 17:58 [PATCH] Device-mapper submission 6/7 Joe Thornber
2002-10-15 18:15 ` Jeff Garzik
2002-10-15 18:59   ` Greg KH
2002-10-15 21:44   ` Joe Thornber
2002-10-16 14:20     ` Jeff Garzik [this message]
2002-10-16 14:38       ` Anton Blanchard
2002-10-16 15:20         ` Jeff Garzik
2002-10-16 15:20       ` Joe Thornber
2002-10-16 15:59         ` Jeff Garzik
2002-10-17  8:05           ` Joe Thornber
2002-10-17  8:26             ` Andi Kleen
2002-10-17  8:50               ` Joe Thornber
2002-10-17 16:54                 ` Jeff Garzik
2002-10-18 11:38                   ` Jakob Oestergaard
2002-10-17 15:10               ` Jeff Garzik
2002-10-18  0:48                 ` Andi Kleen
2002-10-17  0:46         ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DAD75AE.7010405@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=davej@suse.de \
    --cc=joe@fib011235813.fsnet.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.