linux-kernel - Re: [GIT PULL] DRBD for 2.6.32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 25 Sep 2009 11:59:08 +0200
From:	Lars Marowsky-Bree <lmb@...e.de>
To:	Neil Brown <neilb@...e.de>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	lars.ellenberg@...bit.com, arjan@...radead.org,
	jens.axboe@...cle.com, hch@...radead.org, James.Bottomley@...e.de,
	linux-kernel@...r.kernel.org, drbd-dev@...ts.linbit.com,
	akpm@...ux-foundation.org, bart.vanassche@...il.com,
	davej@...hat.com, gregkh@...e.de, kosaki.motohiro@...fujitsu.com,
	kyle@...fetthome.net, torvalds@...ux-foundation.org,
	nab@...ux-iscsi.org, knikanth@...e.de, philipp.reisner@...bit.com,
	sam@...nborg.org, Mauelshagen@...hat.com
Subject: Re: [GIT PULL] DRBD for 2.6.32

On 2009-09-25T15:27:40, Neil Brown <neilb@...e.de> wrote:

> > Enterprise vendors don't pick up the latest kernel. So I think that we
> > need more.

Enterprise kernel providers tend to accept the burden of supporting
their enterprise releases. While I appreciate the thought from the
community, I think the enterprise kernels already including drbd would
be extremely happy to see it officially included.

> I don't really follow your logic, but that isn't important.  I think
> that we need to be open to deprecating old ABIs, particularly when the
> ABI is largely used by just one or two programs or libraries.  This is
> the case for md/dm/drbd and similar devices.

It is even one step beyond this here. The additional ABI effort is
raised as an objection to merging drbd, and the drbd developers and user
community is offering to depreciate it within a reasonable timeframe of
a better ABI existing (since this will be hidden in the user-space
tools), if this means that it can be merged earlier.

This is quite different from an ABI which is expected to be stable and
remain forever (even if it was just an implicit user assumption); the
expectations are set accordingly from day 0, and thus should not be a
hurdle to acceptance.

Regards,
    Lars

-- 
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

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