From: Andrea Arcangeli <andrea@suse.de>
To: "David S. Miller" <davem@redhat.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Mauelshagen@sistina.com, linux-kernel@vger.kernel.org,
mge@sistina.com
Subject: Re: LVM 1.0 release decision
Date: Sat, 12 May 2001 15:39:51 +0200 [thread overview]
Message-ID: <20010512153951.H8259@athlon.random> (raw)
In-Reply-To: <20010511162745.B18341@sistina.com> <E14yDyI-0000yE-00@the-village.bc.nu> <20010511171124.M30355@athlon.random> <15100.18375.367656.3591@pizda.ninka.net> <20010512032453.A8259@athlon.random> <15100.37367.477922.66043@pizda.ninka.net> <20010512045456.E8259@athlon.random> <15100.51153.711892.548545@pizda.ninka.net>
In-Reply-To: <15100.51153.711892.548545@pizda.ninka.net>; from davem@redhat.com on Fri, May 11, 2001 at 10:19:13PM -0700
On Fri, May 11, 2001 at 10:19:13PM -0700, David S. Miller wrote:
>
> Andrea Arcangeli writes:
> > you _must_ know very well what the mainteinance of that code means ;).
>
> Which is why I added the facility by which such ioctl conversions can
> be registered at runtime by the subsystem/driver itself.
Which no one single piece of common code is using yet in 2.4.5pre1 so
right now (2.4.5pre1) you must be doing the mainteinance yourself the
old way.
But I certainly agree that it is promising and that in the future
de-localizing the 32bit wrappers is a good thing so at least people will
see this code when they break it while changing the common code ;).
> I'm already planning on doing this, but it is a 2.5.x project.
> Dave Mosberger agrees with this as has anyone else I've mentioned
> the idea to, so consider it basically done in 2.5.x sometime.
Nice to hear that, when you do that please keep patches@x86-64.org in
CC so we follow it.
After we change the wrapper mechanism by avoiding the mainteinance work by
de-localizing the wrappers and after we share the wrapper logic as well, it
will be a _real_ pleasure to support the lvm ioctl from 32bit userland on
x86-64 too indeed and then it will be a worthwhile effort to support
those ioctl.
Thanks,
Andrea
next prev parent reply other threads:[~2001-05-12 13:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-11 16:27 LVM 1.0 release decision Heinz J. Mauelshagen
2001-05-11 14:32 ` Alan Cox
2001-05-11 15:11 ` Andrea Arcangeli
2001-05-11 20:12 ` David S. Miller
2001-05-12 1:24 ` Andrea Arcangeli
2001-05-12 1:29 ` David S. Miller
2001-05-12 2:54 ` Andrea Arcangeli
2001-05-12 5:19 ` David S. Miller
2001-05-12 13:39 ` Andrea Arcangeli [this message]
2001-05-13 17:36 ` David Woodhouse
2001-05-13 18:39 ` Alan Cox
2001-05-13 23:17 ` Chris Wedgwood
2001-05-13 19:25 ` Christoph Hellwig
2001-05-11 15:42 ` H. Peter Anvin
2001-05-11 17:02 ` Andreas Dilger
2001-05-16 15:03 ` Heinz J. Mauelshagen
2001-05-16 23:38 ` Alan Cox
2001-05-11 14:39 ` Jeff Garzik
2001-05-11 14:48 ` Mark Hahn
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=20010512153951.H8259@athlon.random \
--to=andrea@suse.de \
--cc=Mauelshagen@sistina.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mge@sistina.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox