Mail Archives: cygwin/2006/10/31/15:21:02
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 you
> have to deal with the posix-to-Windows path+permissions+ownership
> translation headaches (i.e. the polar opposite of what cygwin1.dll deals
> with now) since it will be visible to all Windows apps. Both of these
> put it vastly outside the scope of the Cygwin project, which is just a
> regular user-mode library.
No, neither of these do ("put it vastly..."), AFAICS. ioperm already
includes a kernel-mode driver. As for the posix->windows translation, I don't
see how you have to do any such thing at all (nor how posix->windows is the
'opposite' to what cygwin does...); surely you simply make the thing look just
like a windows filesystem to cygwin, and then let the cygwin dll provide the
posix API support. Pretty much the same as how things currently work with FAT
and NTFS access under cygwin...
> If you do it entirely in Cygwin then as you said it's only available to
> Cygwin apps, which sounds fine at first but I think you will find that
> for many people this is a dealbreaker.
Well, all posix features are only available to cygwin apps. I don't
understand what kind of people this could be a "dealbreaker" to: non-cygwin
users perhaps? This is no more of an objection than saying that grep's
dependency on cygwin might be a dealbreaker to some people....
> 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.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
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/
- Raw text -