[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090702113200.39a15f21@lxorguk.ukuu.org.uk>
Date: Thu, 2 Jul 2009 11:32:00 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: tridge@...ba.org
Cc: Pavel Machek <pavel@....cz>,
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
john.lanza@...ux.com, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
Dave Kleikamp <shaggy@...ux.vnet.ibm.com>,
Steve French <sfrench@...ibm.com>,
Mingming Cao <cmm@...ibm.com>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH] Added CONFIG_VFAT_FS_DUALNAMES option
> I think you'll find that most distro makers and most vendors of Linux
> based devices will want to have this patch applied. So if we took the
Good for them
> approach you suggest, then the testing done via kernel.org trees will
> not match what the vast majority of Linux users will actually be
> running. That would seem to be counter to good QA practices.
The vendor trees all contain patches and have done for years, often lots
of them. They will apply the patch if you put VFAT_DUALNAMES into the
kernel as well so your argument is totally bogus. It always was totally
bogus, it always will be. Vendors do not use the base kernel as is in
normal product. They ship
Base kernel
+ Patches for packaging systems
+ .1/.2/.3 bits
+ Cherry pick of stuff that deals with bugs they think have to be
stomped by some means
+ drivers they add which are not yet fit for kernel
+ exciting stuff they think is cool and makes their distro
special (eg KMS patches)
Its starting to sound like the Foundation and someone have signed some
kind of settlement to get this change into the Linux kernel regardless of
the technical issues, practicality or community and this is all for show
anyway.
> If the patch had significant negative consequences for normal use then
You said yourself it can crash XP.
> If we get some real examples of devices that are badly affected
XP crashing by suprise if you are really really unlucky strikes me as a
good example and one you provided.
You've also ignored entirely the fact that this isn't a VFAT file system
so irrespective of whether this goes in it should not be used for mount
-o vfat.
There is a clear end user expectation that vfat means "microsoft fat with
extended names". By all means add support for "not vfat" but don't call
it "vfat" as that is misleading an interface breakage.
--
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