[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090709171501.GA2991@infradead.org>
Date: Thu, 9 Jul 2009 13:15:01 -0400
From: Christoph Hellwig <hch@...radead.org>
To: Theodore Tso <tytso@....edu>, Alan Cox <alan@...rguk.ukuu.org.uk>,
James Bottomley <James.Bottomley@...senPartnership.com>,
tridge@...ba.org, Martin Steigerwald <Martin@...htvoll.de>,
Jan Engelhardt <jengelh@...ozas.de>,
Rusty Russell <rusty@...tcorp.com.au>,
Pavel Machek <pavel@....cz>, john.lanza@...ux.com,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel@...r.kernel.org,
Dave Kleikamp <shaggy@...ux.vnet.ibm.com>, corbet@....net,
jcm@...masters.org
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions
On Thu, Jul 09, 2009 at 11:25:41AM -0400, Theodore Tso wrote:
> Look, even if what you say is valid (despite the advice of lawyers),
> it is still useful for us to apply the patch (with the CONFIG option)
> in the upstream sources. It means that support for the workaround
> stays in the mainstream sources, so we don't have to worry about
> separate patch going no longer applying as time goes by and the
> upstream sources change over time. *If* a vendor really wants to
> strip out the source code, they can do that easily enough using
> unifdef to strip out the one specific CONFIG option.
By putting it in the kernel tree we would only give the bogus patent
claims more credit. And so far no one has but IBM has actually care
about the patch. Tridge can put the patch into the IBM kernel tree for
the service processors if you really deeply care, but can we leave the
rest of the world alone?
If someone really wants a patch to corrupt their filesystems they know
where to find it.
--
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