Date: Thu, 5 Jan 2006 13:43:49 +0100 From: Richard =?iso-8859-1?q?K=E4stner?= <richard.kaestner@ycn.com> To: freebsd-questions@freebsd.org Cc: Oliver Fromme <olli@lurza.secnetix.de> Subject: Re: mapping [process|socket|...] to Filesystem Message-ID: <200601051343.49369.richard.kaestner@ycn.com> In-Reply-To: <redirect-510010@vector01.rfk.priv> References: <redirect-510010@vector01.rfk.priv>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 05 January 2006 12:12, Oliver Fromme wrote: > > 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. Again, it was one of my original questions: 'is my idea simply stupid ?' And, yes, the communication via http is already working - nothing great. It was simply the idea to go one step further: wrap some of functions into= =20 kind of 'file-transfer' from the client's point of view. The idea (to me) still is tempting - but I will look at samba-vfs modules,= =20 possibly also fuse - which are clearly in userland. (I fully agree with the common guideline: as few as possible in kernel !) regards Richard =2D-=20 Mit freundlichen Gr=FC=DFen Richard K=E4stner EDV-Beratung Woerthgasse 17 2500 Baden Austria
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601051343.49369.richard.kaestner>