[3554] in Release_7.7_team
Re: Re-opening NTFS discussion?
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Oct 5 00:32:29 2002
From: Greg Hudson <ghudson@MIT.EDU>
To: William Cattey <wdc@mit.edu>
Cc: release-team@mit.edu
In-Reply-To: <1745AD5A-D816-11D6-B35D-000393995C5C@mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 05 Oct 2002 00:32:24 -0400
Message-Id: <1033792344.16821.25.camel@error-messages.mit.edu>
Mime-Version: 1.0
On Fri, 2002-10-04 at 23:54, William Cattey wrote:
> Paul's take on the situation was that if we're consumers of the
> software, not developers of it, it would provide an opportunity to
> foster interoperability. If Microsoft made an issue of it, it would be
> an opportunity to press them for a reason why we should not be
> interoperating. ;-)
I'm not especially comfortable with "we can infringe on their patents
because we could ask them embarassing questions if they call us on it."
Microsoft has already demonstrated that they are not interested in
interoperating when it comes to filesystems (or office suite document
formats).
If we can obtain patent licenses from Microsoft (unfortunately, I do not
know which patents are at issue), or find out what Red Hat's legal
concerns are and get an in-house legal opinion that they are unfounded,
then I'd be comfortable with either of those.
> I consider such an enhancement as NTFS support under Linux Athena less
> important than disconnected operation, but I feel it IS appropriate to
> re-open the discussion and ask:
> Where would the NTFS filesystem support module come from?
Based on what Andrew wrote: there is source in the 2.4 kernel tree, but
it's not very robust, particularly for SMP machines. So for the short
term we'd have to go with the back port from linux-ntfs.sourceforge.net.
> What is our estimate of the difficulty of adding it?
It's a matter of writing icky build scripts to build the appropriate
code as a module, and then do that for each of the kernel configurations
Red Hat ships RPMs for. A brief glance at the available materials
suggests that the code is not packaged for our particular situation, so
the scripts would be especially icky. Days to weeks of effort for
Andrew or Garry.
> What is our estimate of the ongoing support to keep it in and working?
As long as we're using the backport from sourceforge, we're in for a
potential nightmare of version incompatibilities. Red Hat releases a
kernel update which subtly changes the kernel module API, forcing an
update of the NTFS backport which may or may not be forthcoming from the
outside community, and which may or may not require us to take lots of
other changes we don't need at the same time. We don't have serious
problems in this area with OpenAFS because we are tightly coupled with
the OpenAFS developers; we have no such advantage with NTFS.
Switching from the linux-ntfs.sourceforge.net code to the in-tree code
(when we go to Linux 2.6, several years in the future) would require
rewriting our icky build scripts. Once we've done that, we'd be fairly
safe from version skew.
> (Note, I've CC'd pbh
Doesn't look like you did from my end.
