Does anyone use 9P2000.u anymore?
Can we just remove it from the p9p tree?
Last summer when I was banging my head against the bug in alloctree I
got it all to work when I removed 9P2000.u and some other stuff from
lib9p/srv.c. At that time I got a comment back that the patches I
proposed wou
The compound 'code-in' follows the pattern of 'be-in' as in 'Human be-in.'
You can google that.
--On Friday, November 05, 2010 15:23 -0400 Jacob Todd
wrote:
Code-in? Could you elaborate?
On Nov 5, 2010 1:22 PM, "EBo" wrote:
Google just announced a code-in. Is Plan9 participating?
EBo --
On Fri, Nov 12, 2010 at 1:07 AM, EBo wrote:
> Does anyone use 9P2000.u anymore?
>> Can we just remove it from the p9p tree?
>>
>
> Last summer when I was banging my head against the bug in alloctree I got
> it all to work when I removed 9P2000.u and some other stuff from
> lib9p/srv.c. At that t
On Fri, Nov 12, 2010 at 12:19 AM, Russ Cox wrote:
> Does anyone use 9P2000.u anymore?
> Can we just remove it from the p9p tree?
>
I don't use it from plan9ports. Not sure if Lucho is still using it
(or variants).
But why does version negotiation muck things up? It seems like if
the other
> But why does version negotiation muck things up? It seems like if
> the other side isn't responding with .u then there shouldn't be any
> issues.
i think that's exactly it. the .u stuff leaks out of the version negotiation
phase and changes the behavior of other messages.
- erik
> I don't use it from plan9ports. Not sure if Lucho is still using it
> (or variants).
>
> But why does version negotiation muck things up? It seems like if
> the other side isn't responding with .u then there shouldn't be any
> issues.
It just complicates everything, especially in a
protoco
On Fri, Nov 12, 2010 at 9:55 AM, Russ Cox wrote:
>> I don't use it from plan9ports. Not sure if Lucho is still using it
>> (or variants).
>>
>> But why does version negotiation muck things up? It seems like if
>> the other side isn't responding with .u then there shouldn't be any
>> issues.
I never much liked .u so I'm happy to see it go away :-)
But I wonder what the failure of .u says about the version mechanism.
In the 9p stuff I did in 1998 for linux I used the SunRPC way of
handling protocol variants: client asked to do an op (e.g. Treadlink)
and got back an ENOSUPPORT if server
> And, finally, errno and errstr. Plan 9 speaks strings, Unix integers,
> Windows strings IIRC. The solution for unix clients was reverse
> mapping of errstr to errno, which has not worked well for me. I'd
> still prefer the format I used before:
> sprint(rmsg.error, "%d:%s", errno, errstr);
> and
On Fri, Nov 12, 2010 at 1:55 PM, ron minnich wrote:
>
> That might work but Plan 9 servers currently silently discard T
> messages they don't understand, so this way of determining server
> capabilities can't be used.
>
Silent discard is a bit unfriendly and likely to hang the client.
Returning R
On Fri, Nov 12, 2010 at 2:23 PM, erik quanstrom
wrote:
>
> since plan 9 assumes that strings are null-terminated but
> 9p has explicit rle, one could send uids/errorno after the 0,
> but before the rle says the string is done.
>
> sleezy, and hackish, but it should work.
>
FWIW I think this is a
On Fri, Nov 12, 2010 at 12:31 PM, Eric Van Hensbergen wrote:
> On Fri, Nov 12, 2010 at 2:23 PM, erik quanstrom
> wrote:
>>
>> since plan 9 assumes that strings are null-terminated but
>> 9p has explicit rle, one could send uids/errorno after the 0,
>> but before the rle says the string is done.
>
On Fri, Nov 12, 2010 at 12:30 PM, Eric Van Hensbergen wrote:
> Not really, the intent was that servers could implement a subset of
> the .L features, and return Rerror for any that they don't.
Wonderful! Floren is already fixing plan 9 servers to work this way anyway :-)
> That isn't currentl
On Fri, Nov 12, 2010 at 2:55 PM, ron minnich wrote:
> I never much liked .u so I'm happy to see it go away :-)
> But I wonder what the failure of .u says about the version mechanism.
I think it says you shouldn't use it to change the
encoding of existing messages. Add messages
all you want (and
On Fri, Nov 12, 2010 at 2:41 PM, ron minnich wrote:
>> Doesn't really work in multi-account environments where uid on one
>> system doesn't equal uid on the other system. Also introduces
>> potential parse problems.
>
> but names are not guaranteed to be the either, right? I don't see that
> name
On Fri, Nov 12, 2010 at 2:15 PM, Eric Van Hensbergen wrote:
> No, that's true. I think this is actually a huge open issue for
> existing distributed file systems in general and I'm not sure of a
> good way around.
yeah, we had lots of discussion of this about 8 years ago with 9grid
and never wo
Someone send me a patch to expunge .u and I will apply it. :-)
Russ
where's mine. i have begun a world fair style video. but without
brucee in the disney spinning cups it won't be the same.
obrigado
On Thu, Oct 28, 2010 at 12:13 AM, Eric Van Hensbergen wrote:
> kk, gotta get a stretch of time to babysit ripping the tapes. We are
> about halfway through.
>
>
I can't help it, this one struck me as quite funny, after all the
shared library discussions we've had on this list.
"A Stanford researcher, Philip Guo, has developed a tool called CDE to
automatically package up a Linux program and all its dependencies
(including system-level libraries, fonts, et
> So they've made the whole shared library mess so incredibly complex
> that you now have to bundle a program's shared libraries with the
> program!
>
> Un-bee-lievable.
>
> The standard rule is, when you're in a hole, stop digging; that seems
> not to apply in software nowadays.
why does th
So now bin/ls is going to weigh 200 megabytes on SomeDistro thanks to
a packaging of localities, terminal colours, etc? Sounds great.
On Sat, Nov 13, 2010 at 12:26 AM, erik quanstrom wrote:
>> So they've made the whole shared library mess so incredibly complex
>> that you now have to bundle a pro
On Sat Nov 13 02:34:14 EST 2010, don.bai...@gmail.com wrote:
> So now bin/ls is going to weigh 200 megabytes on SomeDistro thanks to
> a packaging of localities, terminal colours, etc? Sounds great.
i can't wait. in 200-odd megabytes you can have
(a) a plan 9 distribution, or
(b) linux /bin/ls
-
cinap did years ago for linux emu
http://9hal.ath.cx/usr/cinap_lenrek/lbun/mklbun
which packages linuxemu, the linux exec you want and the
required libs all in an rc bundle that you can execute
as a regular program
in:
http://9hal.ath.cx/magic/webls?dir=/usr/cinap_lenrek/lbun
you have lbuns for
23 matches
Mail list logo
