Date: Thu, 5 Jan 2006 12:08:33 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-fs@FreeBSD.ORG Subject: Re: mapping [process|socket|...] to Filesystem Message-ID: <200601051108.k05B8XRR029205@lurza.secnetix.de> In-Reply-To: <76f962c60601041453n1d195cd6s@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Lou Kamenov <loukamenov@gmail.com> wrote: > On 04/01/06, Oliver Fromme <olli@lurza.secnetix.de> wrote: > [..] > > It would be much easier to use HTTP instead of (ab)using > > file system operations. Just install an Apache web server > > on your server machine and write a small CGI. The Windows > > clients can simply use a web browser to upload their data > > to your CGI. Then your CGI does whatever is necessary to > > communicate with your black box, and sends the result back > > to the client's web browser. > > representing different resources as files is not a new concept.. but > rather an old one. look at plan 9. Right. Or look at devfs, procfs, fdescfs, portalfs etc. However, being able to represent resources or information via the file system does not necessarily mean that it is a particularly good idea to do so. For example, I think that procfs does not really make much sense. Especially Linux' procfs is a bad example of cramming too many things into the file system which do not belong there; it's just a big mess. It might be "cool", it might be "easy to do, so lets do it", but it's horribly inefficient and does not make sense. Another important point is the common guideline that as few things as possible should be implemented in the kernel. The kernel should provide interfaces to the hardware and to essential kernel facilities, but everything else should happen in userland. Richard is trying to implement a rather simple client-server mechanism to access a certain device on a server machine (I assume that there is already a driver for that device). There is no sane reason to do that on file system level. Handling it in userland is much more robust, easier to recover in case of problems, and easier to debug. However: YMMV, of course. :-) Best regards Oliver PS: By the way, there's also the opposite of the concept "everything is a file": There's a very interesting concept of an OS which is designed to work completely without the conventional notion of files. It only has processes. All data that you work with is owned by processes. Therefore it doesn't have a file system, but only swap -- the whole disk is a swap area that holds the processes and their data (persistent across reboots, of course). -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. We're sysadmins. To us, data is a protocol-overhead.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601051108.k05B8XRR029205>