From owner-freebsd-questions@FreeBSD.ORG Thu Jan 5 12:44:01 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3893716A41F for ; Thu, 5 Jan 2006 12:44:01 +0000 (GMT) (envelope-from richard.kaestner@ycn.com) Received: from richardkaestner.com (212-88-187-192.ADSL.ycn.com [212.88.187.192]) by mx1.FreeBSD.org (Postfix) with SMTP id 0BCF443D5C for ; Thu, 5 Jan 2006 12:43:58 +0000 (GMT) (envelope-from richard.kaestner@ycn.com) Received: (qmail 4517 invoked from network); 5 Jan 2006 12:43:54 -0000 Received: from pc-01034.richardkaestner.com (HELO sv01.rfk.priv) (10.200.4.10) by stargate.richardkaestner.com (10.200.254.254) with ESMTP; 05 Jan 2006 12:43:54 -0000 Received: from sv01.rfk.priv (localhost.rfk.priv [127.0.0.1]) by sv01.rfk.priv (8.12.11/8.12.11) with ESMTP id k05Chpo6008645; Thu, 5 Jan 2006 13:43:51 +0100 (CET) (envelope-from richard.kaestner@ycn.com) Received: from localhost (localhost [[UNIX: localhost]]) by sv01.rfk.priv (8.12.11/8.12.11/Submit) id k05ChnSw008644; Thu, 5 Jan 2006 13:43:49 +0100 (CET) (envelope-from richard.kaestner@ycn.com) X-Authentication-Warning: sv01.rfk.priv: rfk set sender to richard.kaestner@ycn.com using -f From: Richard =?iso-8859-1?q?K=E4stner?= To: freebsd-questions@freebsd.org Date: Thu, 5 Jan 2006 13:43:49 +0100 User-Agent: KMail/1.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200601051343.49369.richard.kaestner@ycn.com> Cc: Oliver Fromme Subject: Re: mapping [process|socket|...] to Filesystem X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard.kaestner@ycn.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2006 12:44:01 -0000 On Thursday 05 January 2006 12:12, Oliver Fromme wrote: > > Lou Kamenov wrote: > > On 04/01/06, Oliver Fromme 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