Re: [GIT PULL] DRBD for 2.6.32

From: Neil Brown
Date: Wed Sep 23 2009 - 19:05:33 EST


On Wednesday September 23, fujita.tomonori@xxxxxxxxxxxxx wrote:
> On Tue, 22 Sep 2009 08:20:34 +0200
> Lars Marowsky-Bree <lmb@xxxxxxx> wrote:
>
> > On 2009-09-22T07:27:21, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote:
> >
> > > > If it happens, once that happens, that _will_ be an ABI break.
> > >
> > > You misunderstand the raid unification.
> > >
> > > We will not unify the kernel<->userspace configuration interface
> > > because we can't break the kernel<->userspace ABI.
> >
> > I disagree here. Who says we can't over time, and with due notice?
> >
> > For sure, the new ABI needs to co-exist with the old ones for a while,
> > until it is proven and fully complete, but then, why can't the old one
> > be marked as depreciated and phased out over 1-2 years time?
>
> Let me know If you find a Linux storage developer who say, "Yeah, we
> can remove the md ABI over 1-2 years time after the raid unification".

I would have said 3-5 years, that being about the time frame for
enterprise releases, and it would be best if every enterprise vendor
got to have a release that supported both the old and the new
interface. But I don't have a problem with migrating to a better ABI
is we actually had a better ABI.
>
> Seems that you have a very different idea from other kernel developers
> about the stable ABI.

CONFIG_SYSFS_DEPRECATED_V2 seems to suggest that other kernel
developers understand that we sometimes make mistakes and need to
deprecate them.


However I think this is all very premature as there is even a coherent
proposal for what unification might look like, let alone broad
agreement or implementation. I would *much* rather we spent our
energies debating that than debating whether or not DRBD should get
merged.... Maybe would should only accept votes on "Should DRBD get
merged" from people provide constructive input to the question "what
would a unified virtual block device model look like".

>
> Improving the existing framework is a proper approach.

Yes. So let's do it.

NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/