site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 21-May-07, at 10:21 , Amanda Walker wrote: Ad-hoc operations are not established or standard operating methods. I'm not sure I follow how this relates to FUSE, however. Adding to this: Andre _______________________________________________ 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... On May 21, 2007, at 8:05 AM, Dan Shoop wrote: Production is about maintaining and running operations according to set service levels using established procedures and methods. That places the two rather at opposites. FUSE is just a well defined API for implementing a file system in a userspace process rather than in the kernel--it is to file systems what pseudoterminals (ptys) are to character devices. If anything, by defining a stable (and OS-independent) API, FUSE is less "ad hoc" than the methods used for implementing userspace file systems in userspace in the past (webdav, the automounter, and so on). Now, this certainly makes it easier to prototype a new file system implementation than writing a kernel VFS plugin is, but that's orthogonal to the quality of any given implementation, which is what matters for whether or not you'd use it in production. And since a defect in the file system module won't cause a kernel panic, one could argue that at any given quality level, a userspace implementation may well be *more* robust than a kernel implementation. Quality can only be defined in terms of a set of metrics. If these metrics are well defined, then whether the driver is kernel-space or user-space it is immaterial. The basic premise for a good driver is that is does the job properly without bring down the operating system. Moving a driver into user space avoids the potential of bringing down the OS, but still has the basic premise of 'should do the job properly without crashing'. In fact this basic premise applies to any piece of operational code, no matter where it is in a running system. A read only file system has the requirement that it reads the data on the disc in such a way that what the rest of the operating environment sees corresponds to what is on disk. A filesystem that allows writing to disk has the extra requirement of ensuring that the data on disk represents what was written and is consistent. Writing a read only filesystem is much easier to do, since you don't have to worry about long term data corruption. It is for reasons such as this, I believe, that the NTFS kernel driver is read only. While FUSE makes it easier to write a driver, the metrics for quality control stay the same (especially if your reputation matters). An extra benefit that I perceive is potentially larger user base and pool of expertise. What I mean by this last point is that since a FUSE driver does not require intricate knowledge of the low-levels of a specific operating system, so we can easily benefit from people developing filesystem on *BSD and Linux. Also because of the potentially larger user base you are going to find more people reporting issues, since in reality some issues only happen in the field.

From my understanding the main advantage of a kernel based driver is that of performance, but as we saw with the evolution from SCSI based CD writers to IDE based CD writers, the increasing performance of the hardware is such that these differences end up being very small, except for the most extreme of conditions. This email sent to site_archiver@lists.apple.com