Re: Fuse
Re: Fuse
- Subject: Re: Fuse
- From: John Davidorff Pell <email@hidden>
- Date: Thu, 17 May 2007 10:16:26 -0700
This whole discussion has been precipitated by Dan's confusion about
the term "user-space". It appears that Dan thinks that "user-space"
is somehow related to a user: i.e. the person sitting in front of the
computer. This is not true. Arguably, "kernel-space" is more related
to the user since all interactions with the user happen via hardware
which is all managed by the kernel.
Dan: "user-space" means not-in-kernel. That's all it means. The
WebDAV filesystem driver is mostly user-space, and is also "system-
space", as you call it. FUSE has nothing to do with "system-space" or
not "system-space", a term which you have made up, it seems. The
question by the OP was whether or not FUSE ought to be shipped with
the system, allowing the WebDAV daemon to be moved to a better API
and allowing other file systems to be in user space as well. Keep in
mind what user space means: not-in-kernel. It does not imply not-
production-quality. If it did, then no computer software anywhere
would be production-quality (except emacs-compiled-into-the-linux-
kernel).
Dan: In the future, please learn the terms being used before adding
your $0.02.
JP
On May 16, 2007, at 10:44 AM, Dan Shoop wrote:
At 10:56 PM +0200 5/14/07, Uli Kusterer wrote:
On 14.05.2007, at 18:56, Dan Shoop wrote:
Moreover since it affects the stability of the OS, and isn't
anywhere ready for prime time nor is it likely to ever be ready
for production, again in part b/c by nature it's a userspace
"thingie", this would still be anathema.
Why would you assert that it'll never be ready for production "by
nature"??? MacFUSE is a facility to move dangerous code out of the
Kernel into user space, where it can't do as much damage.
As we all know FUSE is a project to implement ad-hoc filesystems in
user space. Ad-hoc filesystems are, by nature, not readily suitable
for production. Hence my comment. Furthermore if the filesystem was
production quality it would most likely be implemented within the
system, not a user application. User based applications don't lend
themselves well as production services.
The fact that you even suggest that there could be dangerous code
associated with such a ad-hoc filesystem further speaks to these
issues. The potential for damage you mention here yourself is also
unsuitable in a production environment.
Realize that by "production" we necessarily referring to user
workstations but production systems or application environments
where you "bet your business" on your ability to perform the
production operations required. If your concept of "production" is
a user sitting at their MacBook at the cafe then you may find
running experimental filesystems on an ad-hoc basis an acceptable
risk, but in true production environments such risks from
"dangerous code" that can cause "damage" is unacceptable.
Making DAV under Darwin implemented in FUSE, as the OP suggested,
would, in my opinion be a step backward in reliability, though it
may be more elegant.
I mean it's a nice thought, but given that it's supposed to be
userspace, that the kernel and core OS are quite clearly kernel-
and system-space, that it's not prime time ready, currently and
probably always unstable by nature, and always going to be more
appropriately implemented at a user level that it doesn't belong
as part of the systems.
FUSE *is* the User-Space-Kernel bridge you're looking for.
I wasn't aware I looking for anything.
Nonetheless I am familiar and do use FUSE in a few different OSen.
This doesn't change my view, and informed opinion tempered by by
almost 30 years of experience however.
The actual file systems may be a different story, but MacFUSE
really is something that should be a Kernel service.
Well MacFuse requires a level of kernel support, but now you're
asking for more than this it appears.
It would even improve responsibility on the system. Just look
what happens when you mount an FTP server in Finder, or a WebDAV
server, and how it pretty much freezes the entire system's file I/
O with the spinning beach ball because everyone is waiting for
that FTP or DAV call to return, even those that just wanted to
know what volumes are available.
Did you mean responsiveness?
As for the issue you mention this would seem to be solvable by
other means, and would be something I'd imagine the Darwin
filesystem implementors already have on their radar[sic].
Don't get me wrong, MacFUSE is great, but it's experimental at
best, at least currently.
I agree it's pretty new, but flat-out stating it will never be
ready for prime-time is arrogant, especially considering who the
people working on this thing are, and that they're employed by one
of the pickiest employers out there.
I know who's working on it.
I fail to see how it's arrogant to express either fact or an
opinion, especially since the discussion was invited by the OP.
It's a fact that FUSE creates ad-hoc fileystems. It's further clear
that ad-hoc filesystems are anathema to production. This isn't
changed by whomever works on the project. It's not demeaning to the
FUSE developers to state facts nor is it arrogant as I'm not
claiming any exaggerated sense of my own importance by making any
of these statements.
At 12:31 AM +0100 5/15/07, Finlay Dobbie wrote:
On 14/05/07, Dan Shoop <email@hidden> wrote:
It quite arguably is a filesystem. It's just not *a* filesystem
but a
hook for arbitrary filesystems.
Dan, I had hoped that you would keep your pointless semantics
arguments to the server lists.
And what are you doing?
You're confusing "filesystem" with "VFS plug-in", but that's
hardly surprising.
Again Finlay your attempts to read my mind have failed as I have no
such confusion, thank-you. You might do better to stay on topic
than engage in ad hominem discussions.
Moreover since it affects the stability of the OS, and isn't
anywhere
ready for prime time nor is it likely to ever be ready for
production, again in part b/c by nature it's a userspace "thingie",
this would still be anathema.
You do realise that, for example, webdavfs does all its HTTP
communication from a userspace daemon?
Yes, I do. I also realize that the code for this filesystem is part
of the system, not some third party or ad hoc endeavor. FUSE
filesystems are not system code but user code implemented on an ad
hoc basis and as such -- it's my opinion -- are not suitable or
ready for inclusion in the system at this time.
YMMV.
--
-dhan
----------------------------------------------------------------------
--
Dan Shoop AIM:
iWiring
Systems & Networks Architect http://
www.ustsvs.com/
email@hidden http://
www.iwiring.net/
1-714-363-1174
"The wise man doesn't give the right answers, he poses the right
questions." -- Claude Levi-Strauss
----------------------------------------------------------------------
--
iWiring provides systems and networks support for Mac OS X, unix, and
Open Source application technologies at affordable rates.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
God is dead, now the war shall never end.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Fuse (From: Andre-John Mas <email@hidden>) |
| | >Re: Fuse (From: Dan Shoop <email@hidden>) |
| | >Re: Fuse (From: Filipe Cabecinhas <email@hidden>) |
| | >Re: Fuse (From: Dan Shoop <email@hidden>) |
| | >Re: Fuse (From: Uli Kusterer <email@hidden>) |
| | >Re: Fuse (From: Dan Shoop <email@hidden>) |