mapping [process|socket|...] to Filesystem
richard.kaestner at ycn.com
Thu Jan 5 04:44:01 PST 2006
On Thursday 05 January 2006 12:12, Oliver Fromme wrote:
> Lou Kamenov <loukamenov at gmail.com> wrote:
> > On 04/01/06, Oliver Fromme <olli at 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
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,
possibly also fuse - which are clearly in userland.
(I fully agree with the common guideline: as few as possible in kernel !)
Mit freundlichen Grüßen
More information about the freebsd-questions