Message-ID: <19020.43585.375900.217202@samba.org>
Date:	Thu, 2 Jul 2009 22:38:25 +1000
From:	tridge@...ba.org
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
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

Hi Alan,

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

well, I certainly don't have your experience with kernel development,
but it seems fairly basic to me that if a patch is likely to be in use
by the majority of Linux users (via distros/vendors) that having it in
the upstream kernel makes sense. 

If I'm wrong and a large proportion of distros/vendors won't want this
patch then of course the argument falls down, and in that case it
would seem perfectly reasonable for the upstream kernel not to have
it, or for it to be inactive by default.

Meanwhile it has gone into fatfs-2.6, and linux-next where I hope it
will get some testing. Whether it then goes into Linus's tree for
2.6.32 is a decision for Hirofumi (and presumably Linus if he decides
to weigh in on this). Similarly what the default should be is their
decision. I'm happy that it is getting some testing now, and I hope
that if that testing doesn't show any issues that it will be accepted
for 2.6.32.

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

err, no. The idea for this patch came when I was reading the first lwn
article on the TomTom suit, and because I happen to have a TomTom at
home and like it. I then started investigating and found some ways to
avoid the patent. I do patent avoidance work quite frequently,
although usually for Samba and in that case I just put the patches
into Samba along with the rest of my code.

There is no "settlement" here (who exactly are you saying is settling
with whom??). There is just a patent avoidance patch that I think is a
very good idea, and that I have gone to the effort of getting very
carefully checked by the appropriate experts. I was helped in this by
some extremely good people (such as Paul McKenney, who has a lot of
experience in this area), and I think the result is a good one.

This discussion is not for show. If Hirofumi/Linus or whoever else is
responsible reject the patch then we don't have any secret backdoor to
get it in. All we can do is present the patch and hope to persuade the
kernel community that it is a good idea.

 > > If the patch had significant negative consequences for normal use then
 > 
 > You said yourself it can crash XP.

well, the WindowsXP fastfat driver isn't exactly known as being
stable! Do a search for fastfat bluescreen and you'll find a huge
number of hits on people complaining about it bluescreening when it
opens FAT filesystems created by all sorts of systems (eg. iPods).

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

Other OSes (eg. Windows) don't tend to distinguish between FAT and
VFAT. It is just a FAT filesystem with a varying range of features. On
Linux we've chosen one particular set of features and labelled that
VFAT, then we've chosen a different set of features and labelled it
'MSDOS'. Within what we have labelled as VFAT we have some existing
runtime options that select different varients. I would have liked to
do the 'dualnames' patch as a runtime option, but that doesn't satisfy
the legal requirements.

So I think you're coming at this very much from a Linux centric point
of view (not surprising!), and even there I very much doubt that many
end users think about the intricacies of what FAT filesystem options
they want. Most systems just auto-mount removable media these days
with whatever options the distro vendors choose (or via HAL rules).

Thus I don't think the "end user expectation" is a strong argument for
making this an entirely new filesystem.

It really is up to Hirofumi-san though. If he asks me to redo the
patch so that it creates a new FAT filesystem varient then I'd be more
than happy to do that. I personally think it will create more
maintainence overhead than it is worth, but as the FAT filesystem
maintainer it is certainly his choice.

Cheers, Tridge
--
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