Re: [9fans] Any demand for a supported Windows version of p9port?

[Andrew Simmons]

Steve, thanks for the thoughtful reply. Your solution wouldn’t work for me, but 
it obviously does for you, so go in peace. And the answer to the question in my 
subject line is obviously “No”.

> On Jul 28, 2016, at 10:49 PM, Steve Simon  wrote:
> 
> I have a different approach.
> 
> Personally I have only command line utilities as I keep Plan9 as my desktop 
> (raspberry PI).
> 
> I need to cross compile on windows so I have a tool to cpu into a windows box 
> (called dos).
> This allows me to have a rio window onto a a dos shell.
> 
> It does the trick like cpu(1) to allow me to hop from a plan9 rc(1) session 
> (in a cifs
> mounted directory on the windows box), into an rc(1) session on windows and 
> arrive at the same
> directory. 
> 
> I use 'local 9fs billy' at startup to make sure sam, rio, and all windows can 
> see my windows box,
> thus plumb on windows "just works" to edit files.
> 
> e.g.
> 
> My windows box is called billy (after mr gates) and my plan9 one is custard 
> (nice with raspberry pies).
> 
>   custard% 
>   custard% cat /dev/osversion ; echo
>   2000
>   custard% pwd
>   /n/billy/c/New/Application
>   custard% dos
>   billy%  mswin/osversion
>   Windows 7
>   billy% pwd
>   c:/New/Application
>   billy% 
>   billy% make
>   mingw32-make -s - -C Debug Application.elf 
>   billy% 
> 
> I could port gmake and the gcc cross compiler to plan9 to do this but there 
> would always be
> bits missing and I need to be sure that what I check in can be built by other 
> people working
> on windows.
> 
> It compiles under mingw32 - I started a mingw64 version but never finished 
> the work (sorry).
> The port predates 9pf, I would probably have used that if I had existed. It 
> also contains none
> of the graphics code that 9pf has, so no native windows sam; though I have no 
> need of it in my
> environment.
> 
> This is all available if anyone wants it.
> 
> -Steve
> 

[9fans] (no subject)

[kokamoto]

Subject change to ether Yuk driver for 88E8036

I noticed the 9fans reopen now.
I tried this mail at June 16, 2016, but failed...
I'd like to announce this to all, particulary eric.

I posted a mail to 9fans, but I don't have received that mail,
so retries it to this mailing-list.

I asked the above line for about two weeks ago to 9fans.
Now I got a solution by myself.

The problem was 88E8036(Yukfe) chip has a small amount
of RAM buffer, which eric didn't pay attention.

I tried to may diff file, however, I wrote too many comment lines
on the file, which leads to a fuge sized diff file.
Therefore, I'll write only the differences between the last cdrom
of 9front and myself.
belows are the data:
(please pay attention to ===> lines)
-from here-
1)static Vtab vtab[] = {
0x11ab, 0x4351, 1514,   "88e8036",



2)in buffinit() function:

if(q == Qr || q == Qr + Qportsz){
===>t = end - start;
rrwrite32(c, q + Rpon, t - 8192/8); /* set Rx upper 
threshold, pause on */
===>rrwrite32(c, q + Rpoff, t/4);   /* set Rx lower 
threshold pause off */



3)in phyinit() function:

if((c->feat & Fnewphy) == 0){
u = phyread(c, Phyextctl);
u &= ~0xf70;/* clear downshift counters */
u |= 0x7<<4;/* mac tx clock = 25mhz */
if(c->type == Yukec)
u |= 2*Dnmstr | Dnslv;
else
===>u |= (0<<8 & 3<<8)|(1<<8 & 3<<8);
..
}else{
===>if(c->feat != 0)/* exclude Yukfe */
u |= Ppmdixa >> 1;  /* why the shift? */
if(c->type == Yukfep && c->rev == 0){
}
.
+++ if (c->type == Yukfe){  /* led control */
+++ u = u1 = phyread(c, Phyphy);
+++ u &= ~(0xf <<4);
+++ u |= 0x0b<<4 & 0xf<<4;
+++ phywrite(c, 0x16, u);
+++ u1 |= (1<<8 & 7<<8) <<1;
+++ phywrite(c, 0x18, u1);
+++ }
phywrite(c, Phyintm, Anok | Anerr | Lsc);   /* phy 
interrupt mask */
dprint("phyid %.4ux step %.4ux\n", phyread(c, 2), phyread(c, 3));
}
--- to here -

Kenji

[9fans] linux mount -t 9p permissions problem

[Costin Chirvasuta]

I have ufs (https://github.com/rminnich/go9p/) running on a FreeBSD
box and I'm trying to mount it on linux but the directory has
permission 0:

~$ 9mount -in 'tcp!fs!5640' fs
mount -t 9p -o 
tcp,trans=tcp,name=ctn,uname=ctn,noextend,nodev,uid=1000,gid=1000,dfltuid=1000,dfltgid=1000,port=5640
192.168.0.3 fs
~$ 9mount -i 'tcp!fs!5640' fs
~$ ls fs
ls: cannot open directory fs: Permission denied
~$ ls -ld fs
d- 1 ctn ctn 0 Jul 26 23:52 fs

Any idea how I can fix this? I tried adding umask=0002 as a mount
option but it doesn't seem to work.

Re: [9fans] Any demand for a supported Windows version of p9port?

[Andrew Simmons]

And even though they’re free, you’d presumably say that the price is still too 
high.

> On Jul 28, 2016, at 9:15 PM, Staven  wrote:
> 
> On Thu, Jul 28, 2016 at 01:41:43PM +1200, Winston Kodogo wrote:
>> I was kind of wondering if there was an option for people who like Microsoft 
>> development tools to build Plan9 tools, which are admittedly a minority 
>> taste in the Windows world, without spending several weeks installing 3rd 
>> party tools and then being told how stupid they are.
> 
> If I bought Microsoft development tools, I'd at least expect to be told
> how stupid I am in a timely manner.
> 
> 

Re: [9fans] Virtual Box 5.1 and Plan 9

[cinap_lenrek]

> Ironically 9front is the only variant that does work, because it has a
> driver for virtio-net. Well done cinap and thank you.

nick owens (mischief) deserves the credit for it, i just
reviewed code, suggested changes and helped fixing the
bugs.

--
cinap

Re: [9fans] Any demand for a supported Windows version of p9port?

[Steve Simon]

I have a different approach.

Personally I have only command line utilities as I keep Plan9 as my desktop 
(raspberry PI).

I need to cross compile on windows so I have a tool to cpu into a windows box 
(called dos).
This allows me to have a rio window onto a a dos shell.

It does the trick like cpu(1) to allow me to hop from a plan9 rc(1) session (in 
a cifs
mounted directory on the windows box), into an rc(1) session on windows and 
arrive at the same
directory. 

I use 'local 9fs billy' at startup to make sure sam, rio, and all windows can 
see my windows box,
thus plumb on windows "just works" to edit files.

e.g.

My windows box is called billy (after mr gates) and my plan9 one is custard 
(nice with raspberry pies).

custard% 
custard% cat /dev/osversion ; echo
2000
custard% pwd
/n/billy/c/New/Application
custard% dos
billy%  mswin/osversion
Windows 7
billy% pwd
c:/New/Application
billy% 
billy% make
mingw32-make -s - -C Debug Application.elf 
billy% 

I could port gmake and the gcc cross compiler to plan9 to do this but there 
would always be
bits missing and I need to be sure that what I check in can be built by other 
people working
on windows.

It compiles under mingw32 - I started a mingw64 version but never finished the 
work (sorry).
The port predates 9pf, I would probably have used that if I had existed. It 
also contains none
of the graphics code that 9pf has, so no native windows sam; though I have no 
need of it in my
environment.

This is all available if anyone wants it.

-Steve

Re: [9fans] Virtual Box 5.1 and Plan 9

[Peter Hull]

Thanks, both. I use VB because it works well for what I need it for
(running Linux on Win and Mac) and for me it works better than qemu in that
respect. I'd rather stick to one virtualisation solution if possible.

I've narrowed the problem down to the emulated ethernet card - the Intel MT
PRO/1000 Server was the only card that worked with Plan9 and now it does
not.

So if anyone has any advice on how to debug this I'd be grateful.

Ironically 9front is the only variant that does work, because it has a
driver for virtio-net. Well done cinap and thank you.

Pete




On Thu, 28 Jul 2016 at 08:16 Matthew Veety  wrote:

> I run 9front in virtualbox, and, while I totally agree that its a
> waste of time to test it because they *always* break something in
> vbox, you're pretty safe if you stay on the 4.3 series and 5.0 series
> (on my end: 4.3 on freebsd is tested and 5.0 on windows is tested). I
> know you don't get the latest and greatest features, but it works and
> you can get your work done which is more important than features.
> If you want to try fixing things, I'm sure the patches would be
> accepted, but I don't think you should unless you have *very* good
> reasons to because of how terrible virtualbox is.
>
> --
> Veety
>
>

Re: [9fans] Any demand for a supported Windows version of p9port?

[Staven]

On Thu, Jul 28, 2016 at 01:41:43PM +1200, Winston Kodogo wrote:
> I was kind of wondering if there was an option for people who like Microsoft 
> development tools to build Plan9 tools, which are admittedly a minority taste 
> in the Windows world, without spending several weeks installing 3rd party 
> tools and then being told how stupid they are.
 
If I bought Microsoft development tools, I'd at least expect to be told
how stupid I am in a timely manner.

[9fans] Browsing and editing files with white spaces in their names with Sam.

[trebol55555]

I've put the little changes and the scripts I've wrote here:

https://bitbucket.org/trebol5/trebol_sam

Maybe I'll clean it a little, but I put it there just in case someone
find it useful, I'm not interesting in doing nothing more with it.

Regards,
trebol.

Re: [9fans] Any demand for a supported Windows version of p9port?

[hiro]

just use drawterm on windows and connect to some 9front instance (for
example inside vmware, on the same machine).

i don't think the alternative is worth it.

Re: [9fans] Virtual Box 5.1 and Plan 9

[hiro]

peter: don't listen to mveety, one of his hobbies is setting himself on fire.

Re: [9fans] Virtual Box 5.1 and Plan 9

[Matthew Veety]

I run 9front in virtualbox, and, while I totally agree that its a
waste of time to test it because they *always* break something in
vbox, you're pretty safe if you stay on the 4.3 series and 5.0 series
(on my end: 4.3 on freebsd is tested and 5.0 on windows is tested). I
know you don't get the latest and greatest features, but it works and
you can get your work done which is more important than features.
If you want to try fixing things, I'm sure the patches would be
accepted, but I don't think you should unless you have *very* good
reasons to because of how terrible virtualbox is.

-- 
Veety