Michael, I forget the relative merits of fuse and similar efforts over/under 9p. I do know that one of the advantages of 9p over conventional unixisms is that in Plan9/Inferno *all* interfaces conform to one protocol - whether local, distributed, files or devices. This typically simplifies the utility code down to 10% of normal.
re: what I had in mind... I think you caught a glimpse in your other email. It would not only buy all that, but potentially give you distributed components for nearly free. While I am not sure about the required overhead I do know that it can be quite good with practice. As a note, the per-process namespaces is a feature which has not made it into the linux kernel as far as I know. EBo -- On Tue, 26 Jun 2012 07:42:07 +0200, Michael Haberler wrote: > Am 26.06.2012 um 06:34 schrieb EBo: > >> Also take a look at the p9fs/npfs/v9fs stuff that was recently >> brought >> into the kernel main. There is a server for it available that looks >> interesting. (see http://sourceforge.net/projects/npfs for a place >> to >> start) > > I read into plan9 and Styx a bit, and am unsure what to make of it - > what do you have in mind? > > If the goal is to expose HAL objects in a local file system tree > similar like sysfs exposes kernel internals, I dont immediately see > an > advantage for it over fuse; it's another means of injecting named > objects into the fs tree and hooking operations to them; I might be > missing something fundamental though > > It is conceivable to think about something completely different: a > method for local & remote object access which encompasses state > access > and modification (HAL) as well RPC-style messaging (NML). There's > something to be said for a unified communications mechanism which > supports runtime-named objects, late binding and which is kernel > compatible (NML is none of the previous, leading to duplicity of > mechanisms (e.g. halrmt vs emcrsh - why 2?), debugging, translation > issues like usrmotif.c etc). Having it exposed in the filesystem > would > be a plus. I think remote operation is a valuable asset even > distribution of components has been a bit fallen by the wayside in > linuxcnc. > > To work remotely, it probably needs to look similar like a filesystem > protocol - bind a name to an object, operate on it etc. I'm not sure > whether all operations needed could be naturally funneled through > existing linux filesystem *operations*. The other issue is that > userland gateways like a fuse filesystem probably are real > performance > dogs (that can be fixed, at the expense of extra kernel code though, > at which point fuse aint helpful). > > - Michael > > >> >> On Mon, 25 Jun 2012 16:17:17 +0200, Michael Haberler wrote: >>> Am 25.06.2012 um 15:13 schrieb andy pugh: >>> >>>> On 25 June 2012 12:11, Michael Haberler <[email protected]> >>>> wrote: >>>>> I wanted to learn about Fuse (http://fuse.sourceforge.net/) and >>>>> did >>>>> a prototype halfs which makes the HAL nam > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest in > malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
