Re: [PATCH] Added CONFIG_VFAT_FS_DUALNAMES option

[Alan Cox]

> 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

It's an open list so they can speak their minds here....

> would seem perfectly reasonable for the upstream kernel not to have
> it, or for it to be inactive by default.

You said yourself that the vendors would prefer to simply remove the code
which means they will carry the "unpatch" anyway.

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

That I don't believe for one minute providing the dualnames option (or -t
vfat) does not work in the non VFAT case.

That is

CONFIG_VFAT_DUALNAMES = y
	mount -t vfat		works
	mount -o dualnames=1    works
	mount -o tridgefat	works (gives you dualnames = 0)

CONFIG_VFAT_DUALNAMES = n
	mount -t vfat		fails
	mount -t vfat,-o dualnames=0 maybe works
	mount-o tridgefat	works

I can believe that shipping code supporting vfat dualnames and not using
the option at runtime would be a problem IFF the patent is shown to be
valid and software patents are valid in the USA. Thus for the problem
space you are worried about it needs to be compiled out. Given the GPL
says I can ask for the source to match the binaries I'm very very sure
any worried distro would go further and never ship that source either -
its lower risk/lower hassle.

Question for the lawyers: If the option is runtime but the case of
concern cannot be selected (viz support is not even compiled in is that a
problem. If not then -o dualnames= makes life much easier)

I have no problem with the idea of a compile time option for not doing
true VFAT so certain US people can provide it. I don't howeve believe
anyone will use it because they either

a) think it is a problem and have US issues in which case they will
remove the code entirely as that is the lowest risk option and with
little other internal inconvenience

b) they don't think it is a problem (the vast array of non-US
distributions from Ubuntu to Red Flag) and don't select it.

> end users think about the intricacies of what FAT filesystem options
> they want. Most systems just auto-mount removable media these days

That is precisely why it needs to not mount as vfat

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

Its a name not a file system. As simple as

#ifdef CONFIG_FOO
	register vfat
#else
	register lfat
#endif


To my mind we need to be careful of three things

- Harming the kernel to work around a potentially country specific
  unproven problem for the benefit of a few big corporations only
- Getting into situations where big companies behind closed doors make
  unaccountable decisions about a project they do not own
- Setting trends for country specific fixups. There are a lot of
  countries and if we keep the US happy we have to keep China happy and
  so it goes on. Big corporations employ armies of specialists for these
  purposes and make the gain from it. The community doesn't so it should
  no more carry the pain of it than of long term stable releases and
  supporting five year old vendor kernels

So IMHO

	Put dualnames in by all means - but don't pretend it makes any
	difference on the QA front or concerned vendors would set the
	option - they won't, they'll go further.

	Don't make the non dualnames mode "vfat", it's not, and the very
	fact users are casual about assuming vfat/fat/windows compatible
	is why it is so important. (As an analogy most end users don't
	know that a 'CD' is specified by a pile of specs, they don't
	care. But they most definitely care if their CD won't play on
	everything).

And a question: Is there a trivial way to make tridge fat differentiable
from vfat/fat without Windows noticing. That way HAL can preserve the
type settings given a kernel that supports it.

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