Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct

[Tiago Natel]

2016-02-01 20:03 GMT-02:00 :

> > Is there a reason why lib9p doesn't have a clunk function pointer in Srv
> struct?
>
> what about Srv.destroyfid()?
>
>   Destroyfid
>When a Fid's reference count drops to zero (i.e., it
>has been clunked and there are no outstanding requests
>referring to it), destroyfid is called to allow the
>program to dispose of the fid->aux pointer.
>
>
Thanks for your help! I'd tried using destroyfid to achieve what I need but
failed. I tried today again implement with destroyfid but realized that it
will not fully support what I need.

I'm using a file server for exchange data between 9P clients. When a new
file is created, I create a plan9 channel and two threads (one for handle
reads and other for writes), a write(2) to the file is translated into a
sendp and a read(2) is translated into a recvp on the channel. The channel
could be buffered or not, and then I want to maintain data allocated (aux
related data) anyway, because the file server is a queueing system when
channel have a buffer bigger than zero.

Apart from that, I want to know how many clients have each file opened to
update my stats file. It's possible in any way without a clunk callback?

I'm trying to replace a rabbitmq server with this system, but I have a
requirement for some way of monitoring of queues size, performance of
channels, number of clients connected to each channel (file on dchan), etc,
I need this kind of information for make a comparison with the current
queue system...

Thanks!

--
> cinap
>
>

Re: [9fans] rc exec error behaviour

[Wes Kussmaul]

Now's your chance!

No match for domain "9COULD.NET". >>> Last update of whois database: 
Tue, 02 Feb 2016 17:22:15 GMT <<<



On 02/02/2016 11:52 AM, Skip Tavakkolian wrote:

Autocorrect fail! And yet Apple is winning big. Sigh...

I mean 9pcloud.net 

On Tue, Feb 2, 2016 at 8:46 AM Skip Tavakkolian 
> wrote:


Same here. The namespace manager for 9pcould.net
 is written in Go and most definitely runs on
a (slightly modified) Labs Plan 9, 386.

On Tue, Feb 2, 2016 at 7:47 AM > wrote:

> You got confused. It works (but there are still issues) on
both 9front's
> and Charles' amd64 kernel, but not on 9front's 386 kernel
(since November 2014).

Are you all saying that Go does not work on Plan 9 legacy and
that all
my code is just faking it?

I know Go is broken in my 9vx installation, but that could be
really
hard to fix.  Took a while last time and would have taken
much, much
longer without help from Anthony Martin.

Lucio.




--

Wes Kussmaul
The Authenticity Institute
738 Main Street
Waltham, MA 02451

office +1 781 790 1674
mobile +1 781 330 1881


THIS COMMUNICATION IS INTENDED ONLY FOR THE USE OF THE PERSON TO WHOM IT IS 
ADDRESSED. If it was addressed incorrectly there's not much I can do but ask 
you politely to pretend you didn't see it. Any disclaimer suggesting that the 
sender has some kind of recourse is just wishful thinking.

If I had a message from you that was digitally signed using your Sigillum™ 
identity credential from the Osmio Vital Records Department (http://osmio.ch), 
we could easily and at no cost exchange encrypted messages and files with each 
other.

Re: [9fans] rc exec error behaviour

[Sean Hinchee]

Go 1.5.1 built and is running on 9Front/amd64 I thought, but doesn't on 
9Front/386?


On 02/02/2016 11:11 AM, s...@9front.org wrote:

I think when people say "works" they mean that tip builds.  The
outstanding bugs with the language on Plan 9 are still outstanding
(see the open issues), regardless of which Plan 9 you are running.

I think it's great if someone's programs work. I use a few go programs
(built with go 1.4.2 for both 386 and amd64) daily on 9front without
problems. That said, go 1.5.x (the language) fails to build on 9front/amd64,
but seems to build and work as well as 1.4.2 on 9front/386. The crucial
aspect here is what works and what doesn't work *after* go builds. I think
some people keep making cracks because some funfamental things remain
broken in all versions (see the open issues).

People who didn't notice tip no longer builds on some systems may
(like me) have been content running their existing working binaries.
Not everyone chases updates unless there is an immediate reason to
update.

sl

Re: [9fans] rc exec error behaviour

[sl]

> Go 1.5.1 built and is running on 9Front/amd64 I thought, but doesn't on 
> 9Front/386?

Sorry, my report was precisely backwards.


This is what I have on my
systems:

dl; echo $cputype
386
dl; go version
go version go1.4.2 plan9/386
dl;


fs; echo $cputype
amd64
fs; go version
go version go1.5 plan9/amd64
fs;

#go-plan9 is aware of the details and some investigation was done, but
work stalled out.

sl

Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct

[Skip Tavakkolian]

i'd recommend studying 9pserve.c in plan9port.

On Tue, Feb 2, 2016 at 10:17 AM Tiago Natel 
wrote:

> 2016-02-01 20:03 GMT-02:00 :
>
>> > Is there a reason why lib9p doesn't have a clunk function pointer in
>> Srv struct?
>>
>> what about Srv.destroyfid()?
>>
>>   Destroyfid
>>When a Fid's reference count drops to zero (i.e., it
>>has been clunked and there are no outstanding requests
>>referring to it), destroyfid is called to allow the
>>program to dispose of the fid->aux pointer.
>>
>>
> Thanks for your help! I'd tried using destroyfid to achieve what I need
> but failed. I tried today again implement with destroyfid but realized that
> it will not fully support what I need.
>
> I'm using a file server for exchange data between 9P clients. When a new
> file is created, I create a plan9 channel and two threads (one for handle
> reads and other for writes), a write(2) to the file is translated into a
> sendp and a read(2) is translated into a recvp on the channel. The channel
> could be buffered or not, and then I want to maintain data allocated (aux
> related data) anyway, because the file server is a queueing system when
> channel have a buffer bigger than zero.
>
> Apart from that, I want to know how many clients have each file opened to
> update my stats file. It's possible in any way without a clunk callback?
>
> I'm trying to replace a rabbitmq server with this system, but I have a
> requirement for some way of monitoring of queues size, performance of
> channels, number of clients connected to each channel (file on dchan), etc,
> I need this kind of information for make a comparison with the current
> queue system...
>
> Thanks!
>
> --
>> cinap
>>
>>

Re: [9fans] rc exec error behaviour

[Richard Miller]

> Cinap assured me that go works on 9front.

For some value of "works".

Re: [9fans] rc exec error behaviour

[lucio]

> You got confused. It works (but there are still issues) on both 9front's
> and Charles' amd64 kernel, but not on 9front's 386 kernel (since November 
> 2014).

Are you all saying that Go does not work on Plan 9 legacy and that all
my code is just faking it?

I know Go is broken in my 9vx installation, but that could be really
hard to fix.  Took a while last time and would have taken much, much
longer without help from Anthony Martin.

Lucio.

Re: [9fans] FP register usage in Plan9 assembler

[Steven Stallion]

Hi Giacomo,

It's probably worth mentioning that learning assembly using the Plan 9
assembler is probably a bad idea. *a makes heavy use of pseudo
instructions and registers and unless you're well versed in its
quirks, can be very confusing when looking at more common assembly
dialects. Many instructions are directly encoded in the instruction
stream, largely due to the fact that it is more difficult than it
should be to extend the assembler as architectures evolve*. More
mechanically, Plan 9 makes use of a loader, which causes a number of
operations you would expect to be present in the assembler to be
deferred until later.

None of this is intended to dissuade of course, but as always in Plan
9: caveat emptor.

If you haven't looked already, a good place to start is /sys/doc/asm.ms.

Cheers,

Steve

* The diff to update support for ARMv7-A to 5a came in at over 2800
lines; this was to add a handful of instructions.

On Mon, Feb 1, 2016 at 10:47 AM, Giacomo Tesio  wrote:
> I'm studying the 9front's amd64 kernel, and I'm pretty new to assembler
> programming, so sorry if my question is too dumb...
>
> I cannot understand the FP pseudo register usage.
> The cpuid function, for example, is implemented as
>
> /*
>  * The CPUID instruction is always supported on the amd64.
>  */
> TEXT cpuid(SB), $-4
> MOVLRARG, AX/* function in AX */
> CPUID
>
> MOVQinfo+8(FP), BP
> MOVLAX, 0(BP)
> MOVLBX, 4(BP)
> MOVLCX, 8(BP)
> MOVLDX, 12(BP)
> RET
>
> What I miss is where "info" comes from. I cannot
>
> Apparently the GAS equivalent is:
>
> .align 4
> .globl cpuid
> cpuid:
> mov%ebp,%eax
> cpuid
> mov0x10(%rsp),%rbp
> mov%eax,0x0(%rbp)
> mov%ebx,0x4(%rbp)
> mov%ecx,0x8(%rbp)
> mov%edx,0xc(%rbp)
> retq
>
> Thus apparently info+8(FP) becomes 0x10(%rsp)
> Why? I know that FP is a pseudo register, but shouldn't it be different from
> SP?
>
> And why info's value is 8? Is it the pointer size?
>
> Another example:
>
> TEXT insb(SB), 1, $-4
> MOVLRARG, DX/* MOVLport+0(FP), DX */
> MOVQaddress+8(FP), DI
> MOVLcount+16(FP), CX
> CLD
> REP;INSB
> RET
>
> should be equivalent to
>
> .align 4
> .globl insb
> insb:
> mov%ebp,%edx
> mov0x10(%rsp),%rdi
> mov0x18(%rsp),%ecx
> cld
> rep insb
> retq
>
> Again I cannot find a definition of address and count, but both seem to be
> be valued as 8, why?
>
>
> Giacomo
>

Re: [9fans] rc exec error behaviour

[Skip Tavakkolian]

Same here. The namespace manager for 9pcould.net is written in Go and most
definitely runs on a (slightly modified) Labs Plan 9, 386.

On Tue, Feb 2, 2016 at 7:47 AM  wrote:

> > You got confused. It works (but there are still issues) on both 9front's
> > and Charles' amd64 kernel, but not on 9front's 386 kernel (since
> November 2014).
>
> Are you all saying that Go does not work on Plan 9 legacy and that all
> my code is just faking it?
>
> I know Go is broken in my 9vx installation, but that could be really
> hard to fix.  Took a while last time and would have taken much, much
> longer without help from Anthony Martin.
>
> Lucio.
>
>
>

Re: [9fans] rc exec error behaviour

[Skip Tavakkolian]

Autocorrect fail! And yet Apple is winning big. Sigh...

I mean 9pcloud.net

On Tue, Feb 2, 2016 at 8:46 AM Skip Tavakkolian 
wrote:

> Same here. The namespace manager for 9pcould.net is written in Go and
> most definitely runs on a (slightly modified) Labs Plan 9, 386.
>
> On Tue, Feb 2, 2016 at 7:47 AM  wrote:
>
>> > You got confused. It works (but there are still issues) on both 9front's
>> > and Charles' amd64 kernel, but not on 9front's 386 kernel (since
>> November 2014).
>>
>> Are you all saying that Go does not work on Plan 9 legacy and that all
>> my code is just faking it?
>>
>> I know Go is broken in my 9vx installation, but that could be really
>> hard to fix.  Took a while last time and would have taken much, much
>> longer without help from Anthony Martin.
>>
>> Lucio.
>>
>>
>>

Re: [9fans] rc exec error behaviour

[David du Colombier]

> For 386, Go barely works. For amd64, current Go doesn't currently work
> on 9front (but works on Charles' kernel), probably due to a kernel
> bug.

You got confused. It works (but there are still issues) on both 9front's
and Charles' amd64 kernel, but not on 9front's 386 kernel (since November 2014).

> Btw, Go broke on 9front about a year ago (or was it more than that?).
> Only one single person noticed, and that was months later after the
> fact. That serves as a useful test to gauge interest (and quality) in
> Go on Plan 9.

Another reason could be that most of 9front users use the
amd64 kernel and not the 386 kernel.

-- 
David du Colombier

Re: [9fans] rc exec error behaviour

[sl]

I think when people say "works" they mean that tip builds.  The
outstanding bugs with the language on Plan 9 are still outstanding
(see the open issues), regardless of which Plan 9 you are running.

I think it's great if someone's programs work. I use a few go programs
(built with go 1.4.2 for both 386 and amd64) daily on 9front without
problems. That said, go 1.5.x (the language) fails to build on 9front/amd64,
but seems to build and work as well as 1.4.2 on 9front/386. The crucial
aspect here is what works and what doesn't work *after* go builds. I think
some people keep making cracks because some funfamental things remain
broken in all versions (see the open issues).

People who didn't notice tip no longer builds on some systems may
(like me) have been content running their existing working binaries.
Not everyone chases updates unless there is an immediate reason to
update.

sl

Re: [9fans] rc exec error behaviour

[David du Colombier]

>> You got confused. It works (but there are still issues) on both 9front's
>> and Charles' amd64 kernel, but not on 9front's 386 kernel (since November 
>> 2014).
>
> Are you all saying that Go does not work on Plan 9 legacy and that all
> my code is just faking it?

No, Go works fine on Bell Labs' 386 kernel.

BTW, I wrote a small Go FAQ a while ago:

http://9legacy.org/9legacy/doc/go/faq.html

-- 
David du Colombier

Re: [9fans] rc exec error behaviour

[Kurt H Maier]

On Tue, Feb 02, 2016 at 06:37:52PM -0600, Sean Hinchee wrote:
> Go 1.5.1 built and is running on 9Front/amd64 I thought, but doesn't on 
> 9Front/386?

That's correct, but the actual point is that it's still full of weird
bugs and is not 100% functional, even after it builds.  Doesn't stop
some good software from working, but it's not like Go on Plan 9 is
reliable.

khm

Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct

[cinap_lenrek]

> I'm using a file server for exchange data between 9P clients. When a new
> file is created, I create a plan9 channel and two threads (one for handle
> reads and other for writes), a write(2) to the file is translated into a
> sendp and a read(2) is translated into a recvp on the channel. The channel
> could be buffered or not, and then I want to maintain data allocated (aux
> related data) anyway, because the file server is a queueing system when
> channel have a buffer bigger than zero.

It is hard to say without seeing the code, but this construction sounds wrong
as recvp() in Srv.read would block the 9p read loop causing you to
not process any other 9p requests when one client is blocked in a read.
You also want to handle flushes otherwise you cannot interrupt/cancel
the blocked read. You can handle this by chaining the Req's that you
cannot satisfy immidiately in a linked list and respond to them from some
other proc or thread once you have data the client could read.

What do you mean by client? You could have multiple Srv's with each
client having its own network connection to it. Or it could mean multiple
attaches (mounts) and a single Srv. Or you it could mean you mean *someone*
reading the file and the state about a "Client" is in the Fid. Anyway,
it sounds like the problem you'r having with destroyfid() is that it doenst
give you access to information whoever is the client of the file closed no?

--
cinap

Re: [9fans] rc exec error behaviour

[Aram Hăvărneanu]

For 386, Go barely works. For amd64, current Go doesn't currently work
on 9front (but works on Charles' kernel), probably due to a kernel
bug.

Either way, Go on Plan 9 is held together with duck tape, especially
networking bits.

Btw, Go broke on 9front about a year ago (or was it more than that?).
Only one single person noticed, and that was months later after the
fact. That serves as a useful test to gauge interest (and quality) in
Go on Plan 9.

-- 
Aram Hăvărneanu

Re: [9fans] FP register usage in Plan9 assembler

[Aram Hăvărneanu]

Yes, on Plan 9, on amd64, only one register is used (as explained by
Charles). Go doesn't use any registers for argument passing (even on
Plan 9).

You can just run 6c -S to see these things yourself.

-- 
Aram Hăvărneanu

Re: [9fans] rc exec error behaviour

[hiro]

> That serves as a useful test to gauge interest (and quality) in Go on Plan 9.

No, only in Go on 9front. It might be that other people are using
their own version of Plan 9 with Go at the same time. Also, what about
people who just don't think it's worth upgrading cause stuff still
works for them?

I don't get the point about quality.