[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090708110451.1092afa7@lxorguk.ukuu.org.uk>
Date: Wed, 8 Jul 2009 11:04:51 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: tridge@...ba.org
Cc: Martin Steigerwald <Martin@...htvoll.de>,
Jan Engelhardt <jengelh@...ozas.de>,
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
Theodore Tso <tytso@....edu>,
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, James.Bottomley@...senpartnership.com
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions
> http://samba.org/tridge/Win98-update.png
>
> When the vendor of an operating system doesn't even bother to display
> a clean "sorry, you don't get updates any more" page for their OS then
> I think it is safe to say that the operating system is dead and
> buried.
There are lots of Win98 systems still alive out there. The "last few" in
the Win98 world is rather a lot due to the original enormous user base.
> that it should be configurable, but I don't think it leads to the
> conclusion that the patch should not be in the upstream kernel at all.
I think we already proved it had no use upstream. Vendors will remove
the code from their source tree if worried about patents so including it
in the base tree is really irrelevant. So I find your argument about this
less than convincing.
The patch serves no purpose but to confuse users and increasingly it is
shown to break systems horribly.
There might have been a limited case for a not-quite-vfat-fs "tridgefat"
etc if it was both more compatible and if the vendors would use the
option. But given its not compatible and vendors won't why bother at all ?
I also note you keep talking about vendors. This is an open list yet I
don't hear a word from the vendors you claim to represent in support of
this patch set, and saying they would enable it. Not one voice seems to
have appeared.
The decision sequence goes something like this
- do we want to ship the feature because of patent concern
> do not ship
- is it less risk to remove the source from our build tree or
configure it out
> remove from the tree
- is there a functionality difference to the user between
removing or unconfiguring it
> No
At that point nobody managing risk is going to do anything but remove the
code that worries them. It's additional risk with no return.
Alan
--
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