[3555] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: Re-opening NTFS discussion?

daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Sat Oct 5 02:47:42 2002

Date: Sat, 5 Oct 2002 02:47:38 -0400
Message-Id: <200210050647.CAA19147@riff-raff.mit.edu>
From: Garry Zacheiss <zacheiss@MIT.EDU>
To: Greg Hudson <ghudson@MIT.EDU>
CC: William Cattey <wdc@MIT.EDU>, release-team@MIT.EDU, pbh@MIT.EDU
In-reply-to: "[3554] in Release_7.7_team"

[ I'm going to start cc'ing Paul, since Bill intended to in the first
place.]

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

   To be fair, there are other commercial distributions that do
distribute the NTFS driver, and Microsoft's giant carnivorous legal
department hasn't destroyed them yet.  Redhat has been sufficiently
vague in every public statement about their concerns that it seems like
a whole lot of FUD.

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

   It would take about 2 days; once one gets over the aesthetic distaste
of the necessary hacks to build the various kernel modules, it's not
that much effort.

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

   I'd say we mostly don't have problems in that area because we don't
upgrade to new Redhat kernels the day they're released, and other people
do the necessary porting for AFS before we're ready to upgrade. It's
also worth pointing out that almost all of OpenAFS's kernel API grief
has come from Redhat's recipe of 13 secret herbs and kernel patches, and
not from the kernel upstream itself; in the long term, it would probably
insulate us from a lot of kernel ugliness to stop using Redhat's
kernels.

   I missed release-team on Wednesday because I wasn't feeling well, but
I'm beginning to think including readonly NTFS support would add a lot
of value in the dual boot environment, and I think we want to seriously
consider the feasability of doing this.

Garry


home help back first fref pref prev next nref lref last post