Re: another IDE cleanup: kill duplicated code

Andreas Dilger
2002-02-12T18:29:21Z

On Feb 12, 2002 16:23 +0100, Martin Dalecki wrote:
> >The later (lv_disk_t) struct isn't used anywhere in the kernel -
> >probably defined for userspace only? That's weird! And also many other
> >structs in lvm.h are nowhere to be found used. Guess we could swipe them
> >out as well.
> >
> >The first lv_read_ahead (in lv_t) removed. And references to it as well.
>
> Yes I know the lvm coders where too deaf to separate user level
> structure layout properly from on disk and kernel space by using just
> different header files for different purposes. And then they tryed
> apparently to embarce anything they could think off, without really
> thinking hard about what should be there and what shouldn't. It was too
> hard for them to have a sneak view on for example Solaris to recognize
> what's really needed.

> diff -ur linux-2.5.4/include/linux/lvm.h linux/include/linux/lvm.h
> --- linux-2.5.4/include/linux/lvm.h Mon Feb 11 02:50:08 2002
> +++ linux/include/linux/lvm.h Tue Feb 12 15:52:45 2002
> @@ -498,7 +498,6 @@
> uint lv_badblock; /* for future use */
> uint lv_allocation;
> uint lv_io_timeout; /* for future use */
> - uint lv_read_ahead;
>
> /* delta to version 1 starts here */
> struct lv_v5 *lv_snapshot_org;

Yes, this is true, but since this struct is passed between the kernel
and user space you can't just delete it, or everyone using LVM has a
broken system and may not even be able to boot if they have root on
LVM. Feel free to delete the code which actually uses this field, but
don't remove it from the struct unless you are willing to fix the user
space code also.

> But they promise perpetually once in a while that the next version will
> be "coming real soon" and be wonderfull... Perhaps someone should just
> stump over them and clean this mess up, with the disrespect those pseudo
> maintainers do deserve....

Well, I don't work on LVM anymore, but the general consensus is that the
current LVM code will die a slow death and be replaced by LVM2 and/or
EVMS. So until that happens, don't screw up everyone using LVM.

Cheers, Andreas
--
Andreas Dilger