From owner-p4-projects@FreeBSD.ORG Tue Sep 20 19:07:21 2005 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 81F3216A421; Tue, 20 Sep 2005 19:07:21 +0000 (GMT) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4590716A420 for ; Tue, 20 Sep 2005 19:07:21 +0000 (GMT) (envelope-from soc-chenk@freebsd.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9055C43D49 for ; Tue, 20 Sep 2005 19:07:20 +0000 (GMT) (envelope-from soc-chenk@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.1/8.13.1) with ESMTP id j8KJ7Kvi085913 for ; Tue, 20 Sep 2005 19:07:20 GMT (envelope-from soc-chenk@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.13.1/8.13.1/Submit) id j8KJ7Kk6085910 for perforce@freebsd.org; Tue, 20 Sep 2005 19:07:20 GMT (envelope-from soc-chenk@freebsd.org) Date: Tue, 20 Sep 2005 19:07:20 GMT Message-Id: <200509201907.j8KJ7Kk6085910@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to soc-chenk@freebsd.org using -f From: soc-chenk To: Perforce Change Reviews Cc: Subject: PERFORCE change 83993 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2005 19:07:22 -0000 http://perforce.freebsd.org/chv.cgi?CH=83993 Change 83993 by soc-chenk@soc-chenk_leavemealone on 2005/09/20 19:06:46 Doc fix: bogus info about device access in IMPLEMENTATION_NOTES corrected Submitted by: soc-chenk Affected files ... .. //depot/projects/soc2005/fuse4bsd2/Changelog#9 edit .. //depot/projects/soc2005/fuse4bsd2/IMPLEMENTATION_NOTES#7 edit Differences ... ==== //depot/projects/soc2005/fuse4bsd2/Changelog#9 (text+ko) ==== @@ -1,3 +1,6 @@ +Tue Sep 20 21:01:08 CEST 2005 at node: creo.hu, nick: csaba + * Doc fix: bogus info about device access in IMPLEMENTATION_NOTES corrected + Tue Sep 20 17:41:17 CEST 2005 at node: creo.hu, nick: csaba * Improved device handling ==== //depot/projects/soc2005/fuse4bsd2/IMPLEMENTATION_NOTES#7 (text+ko) ==== @@ -113,42 +113,28 @@ fuse device can serve no more than one daemon, it's easy: the device name is used to specify the subject of the mount (what a novelty). -In Linux, this couldn't work out this way: there is one fuse device only, -and a fail-safe identification of the subject of the mount is possible -only within the scope of one process. +In Linux, this couldn't work out this way (given the design chosen by +Linux Fuse): there is one fuse device only, and a fail-safe +identification of the subject of the mount is possible only within the +scope of one process. -That in FreeBSD we alter from the Linux way of atomic mounting, is both -a necessity and a possibility. Necessity due to the vnode-based VFS API: -the I/O operations of a device do not know of the file structure via -which they are read/written, so if more daemon were using one device, -the device's I/O routines would get confused, which message is to be -passed to whom. Well, not exactly so, let's make another attempt to -explain. +In FreeBSD, altering from the Linux way of atomic mounting is not a +design choice, it's a must. Unlike Linux, BSDs use a different type of +op vector devices and for regular files (the device access and vnode API +is not unified). The device access API is not only different but almost +completely (struct) file unaware. So we can't distinguish between +different openers of a given device. -The FreeBSD VFS API does have the hooks which can give acces to the -(struct) file via which a given file is opened/read/written. But this -access is fragile, and in case of devices, it's readily broken by devfs -in which devices live, as devfs bastardizes the (struct) files for its -own purposes. (For those who don't know: FreeBSD implements a wisely -designed in-kernel device filesystem.) +The traditional solution would be working with a static set of fuse +devices (nnpfs, the multiplatform userspace vfs framework of Arla has +chosen this solution in its BSD implementations). However, FreeBSD has +a peculiarity which lets us implement Fuse as dynamically as it's in +Linux: a wisely designed in-kernel device filesystem. -So devfs takes away acces from the file structures, but on the other -hand, it makes the current implementation possible: it provides a -mechanism to register event handlers for certain device name patterns, -by which new devices can be spawned on the fly and system call handling -can be delegated. This makes easy to provide a dedicated fuse device to -each Fuse daemon. - -(The imaginative reader might wonder how a Fuse module could be implemented for -other BSDs. Devfs is a FreeBSD specific thingy, so the above musings can't be -applied verbatim to the other flavours. Just as in FreeBSD, Dragonfly's open -handlers have access to the file structure involved [note: this seems to be a -post-fork invention, so the api is slightly different], but no devfs in Dfly; -so a Linux style (struct) file based mount implementation seems to be feasible. -Net's and Open's more traditional open handlers are not file aware. What I can -imagine there is a one-daemon-for-one-device scheme, as in FreeBSD, but with a -static set of fuse devices. This latter design could as well be chosen for -Dfly, of course.) +FreeBSD devfs provides a mechanism to register event handlers for +certain device name patterns, by which new devices can be spawned on the +fly and system call handling can be delegated. We rely on this mechanism +for providing a dedicated fuse device to each Fuse daemon. At this point, one could spot one definite advantage of the Linux way of doing the mount: it's comfortable. That the state of Fuse daemons is