Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Archive:	<http://sourceware.cygnus.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help:	<mailto:cygwin-help AT sourceware DOT cygnus DOT com>,
	<http://sourceware.cygnus.com/ml/#faqs>
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID:	<002301beed88$7df70b30$c8c556d1@hercules>
From:	"Chris Telting" <telting AT sprynet DOT com>
To:	<cygwin AT sourceware DOT cygnus DOT com>
References:	<Pine DOT LNX DOT 4 DOT 10 DOT 9908230922050 DOT 3820-100000 AT www DOT arte DOT unipi DOT it> <000b01beed41$72349b60$cac656d1 AT hercules> <19990823111544 DOT F13837 AT cygnus DOT com>
Subject:	Re: Possibilities for ext2fs
Date:	Mon, 23 Aug 1999 09:56:47 -0700
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE:	Produced By Microsoft MimeOLE V5.00.2314.1300

> 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 AT rocketmail DOT 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 AT sourceware DOT cygnus DOT com

- Raw text -