Re: [9fans] 9n

2018-05-02 Thread Fran. J Ballesteros
I just learned to love absolute paths.
IIRC, there was no deadlock caused that you should be aware of.
I'ts been a long time and quite a few protocols since then, I can look for the 
source; there must be also some docs in the web.
Also, I'm more in favor of prefix mount tables, that they are very different 
from what 9 does and they would lead to a very different system.

Good luck and have fun.

> On 2 May 2018, at 19:14, Giacomo Tesio  wrote:
> 
> 2013-06-17 21:06 GMT+02:00 Nemo :
> You should ask if anyone else did that before doing it, instead of saying
> they are un-spined life forms.
> 
> Here I am, finally! :-)
> 
> I'm designing yet another file protocol for my toy/research os (whose kernel 
> is derived from Charles Forsyth's Plan9-9k), and I'd like to give a look at 
> your prior art.
> 
> Some of my design decisions lead to a management of mount tables that is 
> pretty similar to what you describe in your paper about the integration of 
> 9P2000.ix.
> 
> Given you already walked this path, I'd like to know what you have learnt and 
> if you faced issues I should be aware.
> For example, the slight difference in bind semantics seems to reduce the risk 
> of accidental loops in the namespace, but I would expect it would break 
> related userspace assumptions.
> Also, resolving the dot of each process in the Pgrp each time a mount is 
> done, seems pretty complex and prone to deadlocks.
> 
>  
> Don't you have a tricorder?
> 
> No... but usually I can get away with my sonic screwdriver... :-)
> 
> 
> Giacomo
> 




Re: [9fans] Talk by Charles Forsyth on Feb 1st at Imperial College London, 13:00 -14:00

2018-01-24 Thread Fran. J Ballesteros
will it be avail online, somehow?
thanks. 

> El 24 ene 2018, a las 10:16, Hugues Evrard  escribió:
> 
> Hi all,
> 
> On Thursday Feb. 1st (next week), Charles Forsyth will kindly give an 
> introduction talk to plan9 and inferno at Imperial College in London. If you 
> are in the London area, don't hesitate to join and to relay this announce!
> Here is the abstract:
> 
> Plan 9 and Inferno are two operating systems (originally developed by the 
> Bell Labs centre that produced Unix decades earlier). Both were designed to 
> allow systems to be composed from smaller cooperating systems performing 
> specific tasks. They provide structural support for distribution, at the 
> operating system level. Their defining novelty is the representation of all 
> distributable resources as hierarchical name spaces. There are conventional 
> names for certain resources, but no global name space. Instead, the kernel 
> provides operations that compose name spaces of local and remote resources, 
> at per-process granularity, to build a unique space to suit a given 
> application. That can aid design, development, testing and integration. I'll 
> give brief summaries of the two operating systems, and present examples of 
> their use, with an emphasis on naming.
> 
> The talk is at 13:00-14:00 in amphitheatre 311 of the Huxley building, whose 
> entrance is at 180 Queen’s Gate, London SW7 2AZ. It is part of the iPr0gram 
> talk series ( https://www.doc.ic.ac.uk/~rbc/iPr0gram/ ), where people 
> external to Imperial College are warmly welcome, please just get in touch 
> with Robert ( https://www.doc.ic.ac.uk/~rbc/ ) beforehand if you plan to join.
> As most of you already know, Charles has made numerous contributions to plan9 
> and inferno, and was instrumental in open-sourcing inferno. For more info, 
> check out his homepage: http://www.terzarima.net/
> Please get in touch with me if you would like to have a chat with Charles in 
> the afternoon, I can arrange a meeting room.
> Thanks,
> Hugues
> 


Re: [9fans] The Case for Bind

2017-09-15 Thread Fran. J Ballesteros
I'm going to print your mail, and read it every night. 
thanks. 

> El 15 sept 2017, a las 20:07, Brian L. Stuart  
> escribió:
> 
>> On Fri, 9/15/17, Marshall Conover  wrote:
>> 
>> I'll start digging in to see what I can do. I think I jumped the
>> gun by trying to contribute a feature, ...
> 
> On this point, I'd suggest a slight shift of perspective.  This is something
> that I've tried to convey both to collegues when in industry and to
> students when teaching.  Don't think in terms of implementing features.
> Think instead of implementing mechanisms.  The mindset where every
> feature is implemented with its own mechanisms is the reason so much
> software is so poorly engineered.  Witness the browsers mentioned
> earlier.  Good engineering involves designing and selecting a good
> set of simple mechanisms that when used in various combinations
> provide a rich set of features.  If a mechanism doesn't fit, don't include
> it.  Remember that perfection is achieved not when there's nothing
> left to add, but when there's nothing left to remove.
> 
> Bringing this back to bind, I wouldn't think of bind itself as a feature.
> However, when the bind mechanism is used in conjunction with the
> union directory mechanism and the architecture environment variable,
> the feature of sane multi-architecture binary handling emerges.  No
> where in the source of the shell or the kernel or anywhere else is
> there code specifically designated to make it possible to run the
> correct binary based on the architecture.  Of course, there are
> other ways of accomplishing this feature, such as a path variable,
> but the beauty of this approach is that all of the mechanisms involved
> also find application in other features.  For example, bind and per-
> process name spaces make possible the elegance of rio which
> in turn provides the feature of recursively running rio inside a rio
> window, something that takes a lot of special effort in X.  Likewise,
> when bind is used with import, you can get a particularly elegant
> form of network gatewaying.  So I suggest not thinking of bind as
> a feature, but as a very general tool for building features.
> 
> One objective when implementing a mechanism is that is reduces
> the amount of code in other places by more lines than it takes
> to implement the mechanism.  There are two major reasons why
> it's important to keep the number of lines of code down.  First,
> every line is a potential bug.  To a first approximation, the fewer
> lines of code the fewer places where you might have bugs.  Second,
> every individual and organization has a maximum level of complexity
> that it can manage.  Once that point is hit, all new releases merely
> rearrange the bugs.  They don't really make the product any better.
> 
> A well designed set of mechanisms is like a set of basis vectors
> and each point in the vector space is a potential feature.  If your
> set of features isn't larger and richer than the set of mechanisms,
> then you should go back and rethink the set of mechanisms.  So
> when adding a mechanism, you want to make sure you're adding
> a new dimension to your feature space.
> 
> BLS
> 




Re: [9fans] double lock in proc.c

2017-07-24 Thread Fran. J Ballesteros
do you remember the proposal?
thanks

> El 24 jul 2017, a las 18:39, Erik Quanstrom  escribió:
> 
> I had a discussion with Richard about this a few years ago.  Richard was no 
> longer convinced of the solution.  at the time I agreed with his reasoning.  
> the comment should be changed.
> 
> - erik
> 
> 
> On Jul 24, 2017 9:03 AM, Giacomo Tesio  wrote:
> In /sys/src/9/port/proc.c a comment state:
> 
> /*
> * Expects that only one process can call wakeup for any given Rendez.
> * We hold both locks to ensure that r->p and p->r remain consistent.
> * Richard Miller has a better solution that doesn't require both to
> * be held simultaneously, but I'm a paranoid - presotto.
> */
> 
> (see 
> https://github.com/0intro/plan9/blob/master/sys/src/9/port/proc.c#L882-L887)
> 
> I'd like to know a bit more about Miller's solution as I'd like to simplify 
> postnote.
> Any hint or source code?
> 
> 
> Giacomo
> 


Re: [9fans] Reimplementing Plan 9 in Go (Was: Re: [9front] bio io functions)

2017-05-06 Thread Fran. J Ballesteros
in fact all my machines are using zx now, a 9p descendant. I'm quite happy with 
it. 


> El 6 may 2017, a las 15:17, Fran. J Ballesteros <n...@lsub.org> escribió:
> 
> not yet. 
> sorry for the "was". 
> 
>> El 6 may 2017, a las 15:12, Peter A. Cejchan <tyap...@gmail.com> escribió:
>> 
>> "clive was just another attempt"...oh, no... Clive is dead ???
>> 
>>> On Sat, May 6, 2017 at 10:18 AM, Francisco J Ballesteros <n...@lsub.org> 
>>> wrote:
>>> I don’t now if clive or not,
>>> 
>>> but, I think the world has changed and I’d like to get a plan9 like 
>>> environment
>>> but considering as the HW all the machines I use, including their OS as the 
>>> new “HW”.
>>> 
>>> I’ve been trying to do that since the octopus, clive was just another 
>>> attempt; ideas are welcome :-)
>>> 
>>> 
>>> > On 5 May 2017, at 21:43, Giacomo Tesio <giac...@tesio.it> wrote:
>>> >
>>> > You might find https://lsub.org/ls/clive.html interesting.
>>> >
>>> >
>>> > Giacomo
>>> >
>>> > 2017-05-05 15:25 GMT+02:00 Dave MacFarlane <driu...@gmail.com>:
>>> >> On Fri, May 5, 2017 at 6:21 AM, Stanley Lieber <s...@stanleylieber.com> 
>>> >> wrote:
>>> >>>
>>> >>> Plan 9 has not yet been re-implemented in Go.
>>> >>>
>>> >>> sl
>>> >>>
>>> >>
>>> >> I started trying to do that at one point, but never got my kernel much
>>> >> farther than booting just enough to run "Hello, world!" compiled with
>>> >> 6c on a FAT filesystem in ring 0 and then crashing the system before
>>> >> deciding I don't have the time to finish it or get it somewhere
>>> >> useable. If anyone who has the time is interested in picking it up,
>>> >> contact me off-list and I'll send you a link to my (horribly written
>>> >> and designed) code.
>>> >>
>>> >> I'm more of a userspace kinda guy anyways..
>>> >>
>>> >> - Dave
>>> >
>>> 
>>> 
>> 


Re: [9fans] Reimplementing Plan 9 in Go (Was: Re: [9front] bio io functions)

2017-05-06 Thread Fran. J Ballesteros
not yet. 
sorry for the "was". 

> El 6 may 2017, a las 15:12, Peter A. Cejchan  escribió:
> 
> "clive was just another attempt"...oh, no... Clive is dead ???
> 
>> On Sat, May 6, 2017 at 10:18 AM, Francisco J Ballesteros  
>> wrote:
>> I don’t now if clive or not,
>> 
>> but, I think the world has changed and I’d like to get a plan9 like 
>> environment
>> but considering as the HW all the machines I use, including their OS as the 
>> new “HW”.
>> 
>> I’ve been trying to do that since the octopus, clive was just another 
>> attempt; ideas are welcome :-)
>> 
>> 
>> > On 5 May 2017, at 21:43, Giacomo Tesio  wrote:
>> >
>> > You might find https://lsub.org/ls/clive.html interesting.
>> >
>> >
>> > Giacomo
>> >
>> > 2017-05-05 15:25 GMT+02:00 Dave MacFarlane :
>> >> On Fri, May 5, 2017 at 6:21 AM, Stanley Lieber  
>> >> wrote:
>> >>>
>> >>> Plan 9 has not yet been re-implemented in Go.
>> >>>
>> >>> sl
>> >>>
>> >>
>> >> I started trying to do that at one point, but never got my kernel much
>> >> farther than booting just enough to run "Hello, world!" compiled with
>> >> 6c on a FAT filesystem in ring 0 and then crashing the system before
>> >> deciding I don't have the time to finish it or get it somewhere
>> >> useable. If anyone who has the time is interested in picking it up,
>> >> contact me off-list and I'll send you a link to my (horribly written
>> >> and designed) code.
>> >>
>> >> I'm more of a userspace kinda guy anyways..
>> >>
>> >> - Dave
>> >
>> 
>> 
> 


Re: [9fans] adding TCP half-duplex close

2017-02-04 Thread Fran. J Ballesteros
I used half closes to put go chans in the network for my weird chan based 
network
calls. 
But the code works without such feature. 
Being just that, I dont know if it counts. 

> El 5 feb 2017, a las 5:39, Skip Tavakkolian  
> escribió:
> 
> yes, i'm still trying to find a real situation where this would be critical. 
> i asked go-nuts list for production examples at the same time as the start of 
> this thread. no answers yet.
> 
>> On Sat, Feb 4, 2017 at 3:31 AM Charles Forsyth  
>> wrote:
>> it's also funny that the rationale seems to be to pass the same conformance 
>> test for Go that once had it added to Inferno so it would pass a Java test 
>> but it was never otherwise used for reasons already given, so I took it out 
>> again.
>> 
>> On 4 February 2017 at 10:11, Charles Forsyth  
>> wrote:
>> I did once have a use for this in an o/s of mine, in a sort of network pipe 
>> to servers, but it was so variably implemented by other systems (data was 
>> flushed, or not) I gave it up as not particularly useful in practice, except 
>> between two known systems that did what you wanted.
>> 
>> On 4 February 2017 at 09:58, Charles Forsyth  
>> wrote:
>> 
>> On 4 February 2017 at 01:56, Skip Tavakkolian  
>> wrote:
>> Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and 
>> transition to Finwait1.
>> 
>> i'd make it a "read" or "write" parameter to the existing "hangup" message. 
>> older implementations that don't accept the parameter will give an error on 
>> the request because the current tcp.c doesn't accept a parameter
>> 
>> 


Re: [9fans] Why getenv replaces \0 with spaces in the returned value?

2017-01-18 Thread Fran. J Ballesteros
rc lists?

> El 18 ene 2017, a las 17:45, Giacomo Tesio  escribió:
> 
> Hi, last night I noticed this strange post processing in 4th edition's
> getenv: 
> https://github.com/brho/plan9/blob/master/sys/src/libc/9sys/getenv.c#L34-L41
> 
>seek(f, 0, 0);
>r = read(f, ans, s);
>if(r >= 0) {
>ep = ans + s - 1;
>for(p = ans; p < ep; p++)
>if(*p == '\0')
>*p = ' ';
>ans[s] = '\0';
>}
> 
> Anybody know why this replacement is done?
> It does not seem a good fix to read/write or read/truncate races, but
> I can't find a better explanation.
> 
> 
> Giacomo
> 




Re: [9fans] "The Name Game"

2016-10-08 Thread Fran. J Ballesteros
a great talk. 
Thanks much to all involved. 

> El 8 oct 2016, a las 1:05, Skip Tavakkolian  
> escribió:
> 
> A wonderful and entertaining talk by Charles about key ideas in Plan 9 and 
> Inferno.
> 
> https://youtu.be/3d1SHOCCDn0
> 
> Thanks also to Ron for posting it.
> 


Re: [9fans] server push in 9P protocol

2014-10-15 Thread Fran. j. Ballesteros
the ideas are in Clive, but the code
won't run for 9p or plan 9. 

but I think I copied somewhere (sources)? ix which was ok for a plan9 world, 
but experimental. 

 El 15/10/2014, a las 18:55, Skip Tavakkolian skip.tavakkol...@gmail.com 
 escribió:
 
 search 9fans archives for 9P streaming. i think nemo and lsub crew had 
 experimented with some variation i believe.  i'm not sure if it is brought 
 into Clive, their new effort.
 
 
 On Wed, Oct 15, 2014 at 8:56 AM,  smi...@icebubble.org wrote:
 Hello,
 
 I'm wondering if there is any way to do server push using the 9P
 protocol.  I'm trying to imagine use of 9P for applications such as data
 acquisition.  One example might be caputing MIDI messages from digital
 musical instruments.
 
 As I understand the protocol, if an instrument served MIDI over 9P,
 every MIDI message would have to be explicitly requested with a Tread.
 And the instrument would have to wait for a Tread in order to send data.
 If the instrument (server) sent more than one Rread with the same tag,
 that would be a violation of the protocol.
 
 It might be possible to reverse roles: for the instrument to act as a 9P
 client and treat the MIDI host as a 9P server.  In that case, each MIDI
 message could take the form of a Twrite to the MIDI host.  But that
 would generate a series of Rwrites back from the host to the instrument,
 which would be unnecessary and have to be ignored.
 
 Another example might be isochronous data streams, such as video
 captured at a fixed framerate from a video capture device.  Having to
 send the same Tread or Rread 30x/second seems silly.
 
 So, is there any way use 9P in a server-push mode, where the server
 spits out a stream of data to be captured?
 
 Thanks!
 


Re: [9fans] OT: clive

2014-05-23 Thread Fran. J. Ballesteros
streams of operations on dir structures. the zx.rfs package includes the 
details.
the important part is the interfaces or how it can be used, as shown in the 
examples.

 El May 23, 2014, a las 11:26 PM, Oleksandr Iakovliev yshu...@lynxline.com 
 escribió:
 
 On 2014-05-23 13:54 , Francisco J Ballesteros wrote:
 and includes its new weird file protocol, named zx.
 
 Not sure I have seen some info about zx. What is the protocol?