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-next>] [day] [month] [year] [list]
Date:	Tue, 29 Jun 2010 03:57:34 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Alex Elder <aelder@....com>
Cc:	xfs@....sgi.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/15] xfs: minimize DMAPI footprint

> SGI has a product that uses the DMAPI support code that's
> included in mainline XFS, along with some additional code
> (the "never merged" stuff Christoph refers to) that we
> maintain separately.  To our customers that need it, this
> is an extremely important feature.

So why don't you bother to get HSM support upstream properly,
or at least maintain it somewhere where you can get at it?
What sourcxe tree do those important customers use it?

> What follows is a set of patches that I think accomplishes
> these goals.  The net result of these changes is:

While this is a lot better than the old DMAPI supoort, it's still
lots of dead code in the mainline tree, that won't ever be used
there, as proper HSM suport if it ever was merged would sit at
the VFS layer.

In addition to that the people who effectively maintain XFS for both
the community and lots of paying customers have done a large amount
of work ontop of the DMAPI removal of the last 1 1/2 month.  So I'd
say rebase your changes over

	http://git.kernel.org/?p=linux/kernel/git/dgc/xfsdev.git;a=shortlog;h=refs/heads/for-2.6.36

and keep them in a separate branch dmapi-dev branch where SGI can pull
the code for it's customers from.  This branch could also include the
actual dmapi code and core kernel modifications, so that people that
want dmapi support actually have chance to find a complete kernel tree
for it.  I'd also hope you have fixed grave bugs like the oops on
unmount after multiple mount one I pointed out to SGI about two years
ago, but which still wasn't fixed inthe last dmapi enabled tree.

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ