Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sourceware.cygnus.com
Message-ID: <002301beed88$7df70b30$c8c556d1@hercules>
From: "Chris Telting" <telting@sprynet.com>
To: <cygwin@sourceware.cygnus.com>
References: <Pine.LNX.4.10.9908230922050.3820-100000@www.arte.unipi.it> <000b01beed41$72349b60$cac656d1@hercules> <19990823111544.F13837@cygnus.com>
Subject: Re: Possibilities for ext2fs
Date: Mon, 23 Aug 1999 09:56:47 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> I'm not sure how either politics or design enters into this.

Design because it might involve rewriting all cygwin file
and mount code and creating a subsystem.  Politics
because I can virtually gaurantee that most people wouldn't
like my implementation probably and if it won't be used
why do it?

> If you can create a filesystem driver for NT then you don't have to make
> any modifications to cygwin.  The mount/path code in cygwin is not
> *that* complicated.  It's orders of magnitude less complicated than
> linux ext2 code.

I'm not going to pay a grand for the ms ifs kit or any other ifs kit
just to do something I would give away.  Kernel code for nt is
highly volitile and quite difficult to debug.  That would be too
much of an effort.

A user level subsystem is better for initial development even if
it might be slow.  Then evolve it by moving it to a kernel driver
than an ifs driver with extenstions for cygwin.

> If you're talking about writing a user-level addition to cygwin which
> just "knows" how to access an ext2 file system then I think you're
> widely underestimating the amount of time required for a port.

The linux filesystem code itself I am quite fimilular with.  Porting
that code to a user mode nt dll would relatively be trivial.  Integrating
it into cygwin is the hard part as it might require giving cigwin a
root cancal.  The homework is in understanding cygwin as I havn't
gotten to playing with that code yet.

> I certainly would be interested in seeing this for Cygwin but it seems
> like you have massive amounts of homework ahead of you if you are
> serious about this project.

The homework is in reading a signifigant ammount of the cygwin
source code to figure out how files and everything work and then
rewritting a coherent subsystem which is the only difficult part I
would see in it.

> I'm willing to assist by setting up a cygwin-ext2 mailing list and ftp
> repository, if that helps.

You must work at cygnus.

I never decided to do it.  It can be done in two to three weeks but
is it worth it?  A user mode driver would be slow.  And it would only
work on nt(though something similar might be possible for win9x is
it worth it?).  A kernel driver would be 6 months since it would require
figuring out how to write kernel drivers and filesystem mini-drivers in
cygwin.

In my origional post I was mostly asking if anyone had thought
about such a possability, i.e. if anyone had thought about it
or if development might have been going in a different direction
such as implementing a database to virtualize a unix filesytem
ontop of the current filesystems or implementing stuff using the
ntfs extended attributes, etc...


BlueCoder
bluecoder@rocketmail.com
May you live as long as you wish and love as long as you live.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com