From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 29 Aug 2005 18:23:40 -0500 From: Bhanu Nagendra Pisupati To: 9fans@cse.psu.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [9fans] some Plan9 related ideas Topicbox-Message-UUID: 8134ed92-ead0-11e9-9d60-3106f5b1d025 Hello, I am a PhD student at Indiana University working on the application of some Plan 9 related to the embedded domain. Specifically I am looking at embedded debugging, configuration and device management using the distributed virtual filesystem model. I have looked at a few different types of embedded systems including multi board systems containing SoC's (system on chips) and sensor networks. I have come up with a few different ideas (listed below) to address as part of my thesis work regarding which I hope to get feedback from the wider Plan 9 community. Any thoughts and opinions are greatly appreciated. Thanks in advance, -Bhanu ========================================================================== * Downloadable namespaces The namespace supported by a filesystem can be modified (possibly using a configuration file provided by the filesystem) to correspond to changes in system that the filesystem in encapsulating. For instance, if the filesystem was to abstract a set of sensor networks, then at start up time the user would describe the layout of the network to the filesystem possibly by writing it as an XML description to the configuration file and modify(initialize) the namespace. If the layout of the network changes in due course, the namespace could be similarly modified by using the configuration file to reflect the change. The basic idea is to be able to describe and modify the layout of the namespace of a filesystem namespace dynamically. * 'Tailcall optimizations' for filesystems with other mounted filesystems Consider a filesystem with the layout shown below: FS1 / | \ f1 f2 FS2 / \ f3 f4 Filesystem FS1 contains 2 files (f1 & f2) locally apart from having a mounted filesystem FS2. To a client that mounts FS1, the fact that it has a mounted filesystem (FS2) is transparent. When a client tries to access file in the mounted filesystem (f3 in FS2) then, FS1 passes the request on to FS2 which processes the request hands the result back to FS1 which then returns the result to the client. However this operation could be made more efficient if FS2 could be made to return the result directly to the client rather than sending it to an upstream filesystem. This is analogous to the tail call optimization in compilers where a function call made in the tail position of a subroutine returns directly to the original caller rather than returning to the subroutine and then having it return to the caller. The situation obviously get progressively worse as the number of mounted filesystems in a chain get longer. This idea is based on the VMTP protocol. * Macro messages Lightweight clients (such as microcontrollers) that communicate with a fileserver using 9P protocol over flaky radio connections would benefit from being able to compose several messages (eg: OPEN+READ+CLUNK) together a a single macro packet. This because being able to send one larger packet takes much lesser power than taking multiple smaller packets. Also when multiple devices send data over radio, getting access to a free time slot to communicate is hard. So it makes sense to limit the number of occasions when messages have to be sent. Also if in most cases, the number of operations performed during the time a file is open are small, it limits the number of open files and corresponding the state that needs to be stored for fids. * Stateless variants of 9P This is more hypothetical, but the basic idea is to design and use a variant of 9P which is stateless (or uses little state) and hence better suited for use on devices with little RAM ==========================================================================