site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:from:subject:date:to:x-mailer; b=jXFo5ZJcNSA3mM0+/a0t+YK7Irv3DI2J+TnmCiDa0vHV21hU8D+wcarKqsK4od+b9x75gl0rxpaRbArTtdVs9eOGd38smu99ocyXk2/zMtZWhOEJQ5s2su0pFk4PjLs51I6B2NtnjpmPo6OuTnVR7EJnLT4dvd6o9eNe7cnfh80= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:from:subject:date:to:x-mailer; b=gLWcveF0Zq0t39veAlby8Cf3s67WmYwlN+LLtNSE0zjl0xg13dyRJoEssMN6K7yBKmkA/UUsJXqqyvMEeJrgeX+metYPyzfMmmZLXzcgXU3fnSU2n2OT0KJHG9a3+MkKRKqsNjsDrzWkWPK5tJ3+XPZRzpnmTh/YmUXLrywdEAE= JP On May 16, 2007, at 10:44 AM, Dan Shoop wrote: I wasn't aware I looking for anything. Did you mean responsiveness? I know who's working on it. Dan, I had hoped that you would keep your pointless semantics arguments to the server lists. And what are you doing? You do realise that, for example, webdavfs does all its HTTP communication from a userspace daemon? YMMV. -- -dhan "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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/johnpell%40gmail.com -- God is dead, now the war shall never end. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com 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. 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. 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. 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 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 <shoop@iwiring.net> wrote: It quite arguably is a filesystem. It's just not *a* filesystem but a hook for arbitrary filesystems. 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. 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. ---------------------------------------------------------------------- -- Dan Shoop AIM: iWiring Systems & Networks Architect http:// www.ustsvs.com/ shoop@iwiring.net http:// www.iwiring.net/ 1-714-363-1174 ---------------------------------------------------------------------- -- This email sent to johnpell@gmail.com smime.p7s