Date: Tue, 20 Sep 2005 19:07:20 GMT From: soc-chenk <soc-chenk@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 83993 for review Message-ID: <200509201907.j8KJ7Kk6085910@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509201907.j8KJ7Kk6085910>