Re: [lvm-devel] Re: lvm in 2.5.1

On Fri, Dec 28, 2001 at 01:17:57PM -0700, Andreas Dilger wrote:
> On Dec 28, 2001  17:45 +0100, Jan Niehusmann wrote:
> > On Thu, Dec 27, 2001 at 09:24:51PM +0100, [e-mail] wrote:
> > > hmm, enlarging the dummy[200] in the userspace version of lv_t seems to be a
> > > nice quickndirty solution.
> > 
> > Please do not change the kernel / userspace interface easily. Past
> > experience has shown that this leads to significant update problems,
> > because kernel and userspace tools need to be updated at the same time.
> 
> But since this is a 2.5 kernel, now is the time to change it, but you must
> _also_ change the IOP version in lvm.h to 12 (not 11!) if you change the
> struct sizes.
> 
> Sadly, I think the work that was done in the past to support user tools
> for multiple IOP versions was dropped from (or never added to) the LVM
> build process, so it will not just be a matter of "install the latest
> user tools and all will be well", sigh.  We had this problem with the
> change from IOP6 to IOP10, and had fixed it all up, but we are doomed
> to repeat the same problem over again.

but there is no need to change the kernel-userspace interface. it is just
the __KERNEL__ part that has grown, having different kernel and userspace
lv_t and just converting between them should be enough. this will hopefully
make the interface more stable too. anyhow its broken as it is in 2.5 right
now, with (sizeof(lv_t) in kernel != sizeof(lv_t) in userspace) when the
tools expects it to be. 

it would be nice to be able to use the same tools in 2.4 and 2.5 and i don't
see any reason it shouldn't be possible.

i'm thinking about something like this:

userspace uses lv_t which is about 240 bytes, kern space uses its own _huge_
klv_t and the ioctls converts between them. then we can go adding stuff into
the klv_t without worry.. klv_t could begin with the lv_t so converting it
for sending it to user is simply a cast. getting it from user involves
validating it the convertion almost be in place already.

good that we have uml in 2.5 again so i don't have to be afraid to trash my
laptop disk.

-- 

//anders/g