. The VFAT patent workaround discussion continues, focused
primarily on two points. The first is whether it is appropriate to put
patent workarounds into the kernel. The main opposition comes from Alan
Cox, who asserts that individual companies need to find ways to navigate
around country-specific legal landmines; workarounds for these problems
should not find their way into the upstream code. Besides, Alan claims
that vendors who are worried about patent suits will not be satisfied with
a kernel configuration option; they will hack out the code entirely.
Meanwhile, Andrew Tridgell continues to push for the use of workarounds - a
strategy which has worked well for Samba. Tridge says:
The only weapon we have to fight patents right now is our
collective ability to find smart solutions to problems. The "every
vendor for themselves" approach that you seem to be so keen on
makes that collective approach pretty much impossible.
How this side of things will play out remains to be seen. Meanwhile, there
has also been an extensive technical discussion focused on interoperability
problems caused by the patch. Some of these problems, as explained by Tridge, are really the result of
various existing VFAT mount options; in some cases, even without the patch
under discussion, Linux will create long name entries for names which
appear to fit the 8.3 format. This kind of interoperability problem has
existed for quite some time.
Mount options do not explain all of the problems, though. It seems that
there are some music players out there which understand long names, but
which still require that valid 8.3 names exist. There are also
difficulties with Windows98 which may (or may not) be resolved by changes
in how the patch fills the 8.3 information. Tridge suggests that Windows98
is old enough to not be worth supporting, but not all agree on that.
The checkpatch police. Alan Cox recently proposed the addition of a new
event interface for the virtual terminal driver. Ingo Molnar responded with a list of errors from the
checkpatch.pl script, requesting that they be fixed. Alan's reply was:
Given the code doesn't currently *work* yet but is a first draft
its hardly important and there are better uses of time than playing
What followed was an extensive discussion on the value of checkpatch.pl,
whether code should be checkpatch-clean even before first submission,
whether coding style problems should be fixed piece-by-piece as other
work is done, and so on. Ingo would like to see coding style issues dealt
with early on; among other things, consistent coding style makes reviewing
the code much easier. Alan sees that sort of cleanup as a distraction, to
be done after more substantial issues (which are not lacking in the TTY
code) have been dealt with.
Consensus was not to be had in this discussion; expect this to be one of
those themes which returns regularly to linux-kernel.
to post comments)