From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Wed, 15 Aug 2012 23:27:34 +0200." <20120815212734.GA1190@polynum.com> References: <20120803171847.GA2720@polynum.com> <501D12A1.1060906@yahoo.fr> <20120804152016.GB433@polynum.com> <20120805173639.GA395@polynum.com> <20120815173327.GA424@polynum.com> <20120815200949.4628BB85B@mail.bitblocks.com> <20120815212734.GA1190@polynum.com> Date: Wed, 15 Aug 2012 20:47:47 -0700 From: Bakul Shah Message-Id: <20120816034747.7FE5EB85B@mail.bitblocks.com> Subject: Re: [9fans] Multi-dimensional filesystem Topicbox-Message-UUID: a9e0e334-ead7-11e9-9d60-3106f5b1d025 On Wed, 15 Aug 2012 23:27:34 +0200 tlaronde@polynum.com wrote: > > I will give two (DeLuxe(R) version!) examples. Thanks. Sounds like you are taking about IS-A and HAS-A relationships. > 2) In 9P, the ".." if I'm not mistaken is not here. One can request a > file, or go back to the previous one. The ".." including "path removing" > is not implemented in 9P if I read correctly the manpage. So a client > can speak 9P, but the way the stuff are presented will be mainly in the > server, the trick to allow existing clients to browse being this ".+" > and ".-": ".+" leads to children; ".-" leads to parents and a DESC file > being perhaps a text description, and some fake parenting allowing a > request of ".." to trigger a special action from the server---but all > these are artefacts of the server. Looks like you are treating ".+" & ".-" specially *somewhere*. Are foo/.- and foo/bar treated differently? What would "foo/.-" even mean? What would open("foo/.-", mode) do? When I try to work out an example I don't get how you can implement this. May be you can use your special syntax to present an example or two as shell scripts? In any case since multiple relationships are possible, why single out a specific case? That is, it seems to me you can either use the current 9p as is and implement what you want by convention in your programs or extend the model in a major way (which is where I was going). > >From a very cursory look, it seems to me that it could be simpler to > implement this with Plan9, because it is relatively agnostic about what > is a filesystem, than with an Unix if I take into account the > difficulties Unix kernels have with userland filesystems---probably > because a lot of semantics are assumed in the vnode subsystem. You can use fusefs to implement a plan9 like synthetic filesystems. But compared to plan9 the unix model is indeed far more constrained and a lot more complicated -- you should see Linux's /sys synthetic filesystem -- it is also a good exmaple of what multiple inheritance wreak.