X-Recipient: archive-cygwin@delorie.com
X-Spam-Check-By: sourceware.org
Message-ID: <4846CD6F.40506@x-ray.at>
Date: Wed, 04 Jun 2008 19:14:23 +0200
From: Reini Urban <rurban@x-ray.at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: free NFS client for Cygwin and/or support for FUSE?
References: <000c01c6fd2a$05618a10$a501a8c0@CAM.ARTIMI.COM>
In-Reply-To: <000c01c6fd2a$05618a10$a501a8c0@CAM.ARTIMI.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com

Continuing on that...

Dave Korn schrieb:
> On 31 October 2006 12:47, Brian Dessent wrote:
> 
>> Ben Wing wrote:
> 
>>> Also, has anyone considered building something like FUSE into Cygwin? ...
>>> The result would be Cygwin-specific, i.e. wouldn't work in non-Cygwin
>>> utilities, but that's OK; the benefit of having such a system would be
>>> so great that it would vastly outdo the trouble of not being able to use
>>> non-Cygwin utils.
>> No doubt that many have *considered* it, but nobody has done it (to my
>> knowledge at least.)
>>
>> If you do it right and make it a real filesystem driver, then you both
>> need the expertise and time to code and test a NT kernel module,
> 
>   Yes, of course.  Goes without saying really.
...
>>   And in order to get any patches
>> of this kind accepted by Cygwin maintainers you'd need to show clear
>> evidence that the presence of all this extra code did not affect
>> performance of the standard filesystem access and path translation.
>> That part of the code tends to be somewhat of a sore spot, due to the
>> fact that it is already complex and easy to break, and a critical path
>> performance-wise.
> 
>   I think you worry too much.  The kernel-mode driver would be nicely
> isolated, and we'd just need to add a new fhandler type to interact with it;
> the extra code wouldn't ever be called if not used.

As I understand the issue, we only need to add another fhandler_fuse.cc 
to support /dev/fuse and the rest almost compiles out of the box.

sshfs builds fine and for fuse just the kernel driver (=> 
fhandler_fuse.cc) and our sys/mount.h headers are quirky.

Rationale: I really want sshfs or shfs or such in user-space without any 
ddk .sys involved. A simple ext3 or reiserfs driver can also be built 
upon that.

First I though of dynamic /lib/mount-<filesystem>.so loading when an 
unknown non-windows device is detected in /etc/fstab.
For other windows fs-devices such as NFS or Samba the specialities in 
fhandler_disk_file.cc are probably enough, but using real mount options 
and special support seems to a next step.

But with fuse support it would be even easier.
Delegate all non-windows mount types to fhandler_fuse and simply use the 
already available fuse filesystems.
No kernel drivers need at all.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/