[9fans] gsoc2010 + plan9

[9fans] gsoc2010 + plan9

[Tim Newsham]

Some people were asking on #plan9 -- will there be any GSOC
projects this year?  Time is ticking down.

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

Re: [9fans] gsoc2010 + plan9

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

What's the current state of the following:

1. 9vx
2. 9null
3. Cpu from Inferno to Plan 9?  (i think this might be in npe's inferno
fork)
4. Inferno DS? (Is anyone still interested in it?)
5. SSH2?
6. LinuxEMU improvements?

I'm sure there's plenty of ideas floating around people could work on.

Dave

On Wed, Mar 3, 2010 at 3:09 PM, Tim Newsham <newsham@lava.net> wrote:

> Some people were asking on #plan9 -- will there be any GSOC
> projects this year?  Time is ticking down.
>
> Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
>
>

[-- Attachment #2: Type: text/html, Size: 1091 bytes --]

Re: [9fans] gsoc2010 + plan9

[Venkatesh Srinivas]

On Wed, Mar 3, 2010 at 6:40 PM, David Leimbach <leimy2k@gmail.com> wrote:
> What's the current state of the following:
...
> 3. Cpu from Inferno to Plan 9?  (i think this might be in npe's inferno
> fork)
...

Yep, its there. :D

-- vs

Re: [9fans] gsoc2010 + plan9

[Balwinder S Dheeman]

On 03/04/2010 04:41 AM, Tim Newsham wrote:
> Some people were asking on #plan9 -- will there be any GSOC
> projects this year?  Time is ticking down.

What about?
1) Improving IPv6 stack, particularly the router advertisements part,

   ip/ipconfig -6             # works fine
   ip/ipconfig ra6 recvra 1   # does not work

2) Add support for more SATA/AHCI controlers; I have:

00:02.0 ISA bridge [0601]: Silicon Integrated Systems [SiS] SiS968
[MuTIOL Media IO] [1039:0968] (rev 01)

I think, the above is a PCI bridge, may the Linux lspci -nn is reporting
it wrongly because of [0601] id, which should be [0604]. Neither the
9load nor the kernel recognizes it.

and I saw:

00:05.0 SATA controller [0106]: Silicon Integrated Systems [SiS] AHCI
IDE Controller (0106) [1039:1185] (rev 03)

is seems to be supported by the 9load and, or kernel, but I could not
install neither the plan9 not 9atom on this drive; none of the IDE/AHCI
mode worked, whereas Linux, FreeBSD and Windows-7 are working fine in
AHCI mode.

3) HDA/AC97 Audio controllers

--
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/      Visit: http://counter.li.org/

Re: [9fans] gsoc2010 + plan9

[erik quanstrom]

>
> 2) Add support for more SATA/AHCI controlers; I have:
>
[...]
> 00:05.0 SATA controller [0106]: Silicon Integrated Systems [SiS] AHCI
> IDE Controller (0106) [1039:1185] (rev 03)
>
> is seems to be supported by the 9load and, or kernel, but I could not
> install neither the plan9 not 9atom on this drive; none of the IDE/AHCI
> mode worked, whereas Linux, FreeBSD and Windows-7 are working fine in
> AHCI mode.

should be supported by sdiahci.c already, at least the 9atom
version of it.

if you have a specific failure report, i'd like to hear it.

- erik

Re: [9fans] gsoc2010 + plan9

[Balwinder S Dheeman]

On 03/04/2010 11:42 PM, erik quanstrom wrote:
>>
>> 2) Add support for more SATA/AHCI controlers; I have:
>>
> [...]
>> 00:05.0 SATA controller [0106]: Silicon Integrated Systems [SiS] AHCI
>> IDE Controller (0106) [1039:1185] (rev 03)
>>
>> is seems to be supported by the 9load and, or kernel, but I could not
>> install neither the plan9 not 9atom on this drive; none of the IDE/AHCI
>> mode worked, whereas Linux, FreeBSD and Windows-7 are working fine in
>> AHCI mode.
>
> should be supported by sdiahci.c already, at least the 9atom
> version of it.
>
> if you have a specific failure report, i'd like to hear it.

Well, 9atom did the trick this time, though the installer could not
mount the same medium (/dev/sdE1/data) from which it was booted off :(

The cdrecord/cdrtools 2.01.01a76-1 puked an error related to start
sector, but it burned the disk, which used for boot 9atom.

So I copied the iso image to a dos partition on /dev/sdE0, also needed
to rename it to plan9.iso, because installer does not recognize the
9atom.iso

Everything during the install worked fine, except for a lot of errors
related to some invalid uids on the iso.

Anyway, thanks lot for the great work; all Debian/XEN-dom0, Windows-7,
FreeBSD, Plan9 and Ubuntu desktop are working fine in AHCI mode now :)

--
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/      Visit: http://counter.li.org/

Re: [9fans] gsoc2010 + plan9

[Chad Brown]

> 2) Add support for more SATA/AHCI controlers; I have:

FWIW, GSoC projects that amount to ``add some drivers for my non-linux OS!'' have historically been unpopular, unfinished, and generally unloved projects (perhaps barring last year, when I didn't really pay attention).  I recommend against making them a significant part of your GSoC proposal; I might go so far as to recommend against adding them at all.

*Chad

Re: [9fans] gsoc2010 + plan9

[erik quanstrom]

> > 2) Add support for more SATA/AHCI controlers; I have:
>
> FWIW, GSoC projects that amount to ``add some drivers for my non-linux
> OS!'' have historically been unpopular, unfinished, and generally
> unloved projects (perhaps barring last year, when I didn't really pay
> attention).  I recommend against making them a significant part of
> your GSoC proposal; I might go so far as to recommend against adding
> them at all.

i don't believe i heard that as a specific complaint at the
mentors summit.  perhaps i wasn't listening to the right people.

what i did hear is that many projects suffered from overambition.
students (like all software developers) consistently underestimate
the scope of work and overestimate the rate at which they can
get it done.  also underestimated was the time required to get
a development environment up-and-running.

for drivers, there are often these two additional problems.
students and mentors alike underestimate the difficultiy of
learning multiprogramming.  and porting a driver is generally
much harder than writing a new one from the documentation
because it's hard to tell why a driver casts the runes it does
without (you guessed it) the documentation.

assuming these concerns are addressed, i think mentoring
a driver project could be fun.

for example, there are a number of 10/100 chipsets that have
good documentation that's under 100 pages.  complete with
(oh, my) a theory of operation.  that could be an intersting
project if a dev environment were easy to set up.

a basic smb driver could also fun to do and within the scope
of work for a summer.

- erik

Re: [9fans] gsoc2010 + plan9

[ron minnich]

The big thing I'd like to see as a GSOC project, and which I think is
doable, is a first-class set of drivers for the beagle and/or IGEP.

The beagle is cheap and would be a very nice terminal.

It's close on some fronts. We really need video. USB is not there yet.
There are other problems. At the same time, Geoff has done a great job
of giving us a foundation from which we can work.

It's interesting but watching the way things are going, ARM-based
designs are really taking off. I just visited a vendor who told me
they're churning out just one type of CPU at 1M a month and they're
growing.

I think the opportunities for doing good Plan 9 work on ARM are going
to grow quite a bit. It may well prove a better platform for the
future than PCs, which are increasingly closed and esoteric.

But I think the drivers would not be too hard, I've looked at (e.g.)
the U-boot video driver and think it could go into Plan 9 without too
much trouble. I don't see this as a super-hard project and it would
provide us with a nice platform.

ron

Re: [9fans] gsoc2010 + plan9

[Patrick Kelly]

On Mar 4, 2010, at 4:13 PM, ron minnich wrote:

> The big thing I'd like to see as a GSOC project, and which I think is
> doable, is a first-class set of drivers for the beagle and/or IGEP.
>
> The beagle is cheap and would be a very nice terminal.
>
> It's close on some fronts. We really need video. USB is not there yet.
> There are other problems. At the same time, Geoff has done a great job
> of giving us a foundation from which we can work.

Thats the thing, drivers are the most needed. Fancy programs won't do
you any good if Plan 9 won't even run on your machine.

> It's interesting but watching the way things are going, ARM-based
> designs are really taking off. I just visited a vendor who told me
> they're churning out just one type of CPU at 1M a month and they're
> growing.

That's great news. Personally I wish it was the MIPS, but it'll do.

> I think the opportunities for doing good Plan 9 work on ARM are going
> to grow quite a bit. It may well prove a better platform for the
> future than PCs, which are increasingly closed and esoteric.

I think a broken table would make a better platform than a PC, and it
seems to be getting worse.

It might be worth it to devote a little more effort into non-80x86
platforms. Windows dominates it and won't be moving any time soon, OS
X runs strictly on it, and the GCC is focused almost entirely on it,
Heck most everything run on it.

It certainly seems like there is a slight renewed interest in RISC
machines. Most everyone I know has a laptop, and with the 80x86's
horrid power needs...

Leaning a little towards another platform could turn out to be a good
idea.

> But I think the drivers would not be too hard, I've looked at (e.g.)
> the U-boot video driver and think it could go into Plan 9 without too
> much trouble. I don't see this as a super-hard project and it would
> provide us with a nice platform.
>
> ron
>

Re: [9fans] gsoc2010 + plan9

[erik quanstrom]

> I think a broken table would make a better platform than a PC, and it
> seems to be getting worse.

this may be true.  but can you name another platform?
arm is a cpu grab bag, not a platform.

> It certainly seems like there is a slight renewed interest in RISC
> machines.

alternatve interpretation: old risc designs are cheep to buy and require
few transistors so a 32-bit 200mhz cpu can be produced for $3.

- erik

Re: [9fans] gsoc2010 + plan9

[Georg Lehner]

ron minnich wrote:
> ...
> I think the opportunities for doing good Plan 9 work on ARM are going
> to grow quite a bit. It may well prove a better platform for the
> future than PCs, which are increasingly closed and esoteric.
>
The company i am working for is using ARM processor platforms
for industrial mobile panels since StrongARM. The next generation
coming out this year is using an OMAP3503.

The boards are shipped with VxWork and Windows CE.  From the
first day on i wished to have a Plan9 (or Inferno) port for them,
just for comparison or as a handy terminal.

A Beagle Board port would get me started at least with the newer
devices ...

Regards,

    Jorge-Le�n

Re: [9fans] gsoc2010 + plan9

[geoff]

Can you provide more details of your `ipconfig ra6 recvra 1' failure?
What happens?  What's printed?  What's in /sys/log/v6routeradv (you
may have to create it first)?

It's not worth supporting any new 10Mb ethernet controllers,
and new 100Mb ones are borderline.

Re: [9fans] gsoc2010 + plan9

[erik quanstrom]

On Thu Mar  4 17:15:19 EST 2010, David.Eckhardt@cs.cmu.edu wrote:
> > for example, there are a number of 10/100 chipsets that have
> > good documentation that's under 100 pages.  complete with
> > (oh, my) a theory of operation.
>
> Such as?

and

On Thu Mar  4 20:28:36 EST 2010, geoff@plan9.bell-labs.com wrote:
> It's not worth supporting any new 10Mb ethernet controllers,
> and new 100Mb ones are borderline.

for the pc architechture, this is certianly true.  i would even bias
development toward 10 and 40gbe.

but for other platforms, i think 10/100 chipsets make a lot of sense
today.  10/100 is great for appliance-ish applications/
for example, this is a very interesting bit of hardware
(sorry, ron, mips, not arm)

	http://www.ubiquitistore.com/ls2

an ethernet driver is here

	https://dev.openwrt.org/browser/trunk/target/linux/atheros/patches-2.6.33/110-ar2313_ethernet.patch?rev=19906

it's a mere 1200 lines, which is just trivial in the linux world so if one
were to scare up documentation, it might be quite a dream to
program.

there were a few others i stumbled on recently.  i recall reading
the datasheets for a few spi-based chipsets that looked pretty clean.
(obviously 10mbps.)

- erik

Re: [9fans] gsoc2010 + plan9

[Balwinder S Dheeman]

On 03/05/2010 07:02 AM, geoff@plan9.bell-labs.com wrote:
> Can you provide more details of your `ipconfig ra6 recvra 1' failure?
> What happens?  What's printed?  What's in /sys/log/v6routeradv (you
> may have to create it first)?

cpu% touch /sys/log/v6routeradv
cpu% ip/ipconfig -6
cpu% ip/ipconfig ra6 recvra 1   # no errors

cpu% tail /sys/log/v6routeradv
helix Mar  6 22:47:11 got initial RA from fe80::21d:7dff:fe58:e11f on
/net/ether0; pfx 2001:470:19:333::
helix Mar  6 23:24:04 recvra6 on /net/ether0
helix Mar  6 23:24:11 sendrs: sent solicitation to ff02::2 from :: on
/net/ether0
helix Mar  6 23:24:11 got initial RA from fe80::21d:7dff:fe58:e11f on
/net/ether0; pfx 2001:470:19:333::
helix Mar  6 23:45:01 recvra6 on /net/ether0
helix Mar  6 23:45:08 sendrs: sent solicitation to ff02::2 from :: on
/net/ether0
helix Mar  6 23:45:08 got initial RA from fe80::21d:7dff:fe58:e11f on
/net/ether0; pfx 2001:470:19:333::
helix Mar  6 23:47:42 recvra6 on /net/ether0
helix Mar  6 23:47:50 sendrs: sent solicitation to ff02::2 from :: on
/net/ether0
helix Mar  6 23:47:50 got initial RA from fe80::21d:7dff:fe58:e11f on
/net/ether0; pfx 2001:470:19:333::

cpu% cat /net/ipselftab
127.0.0.0                                    01 6b
192.168.1.0                                  01 6b
ff02::1                                      02 6m
127.0.0.1                                    01 6u
192.168.1.9                                  01 6u
2001:470:19:333:216:3eff:fe79:c0f7           01 6u
ff02::1:ff79:c0f7                            02 6m
fe80::216:3eff:fe79:c0f7                     01 6u
127.255.255.255                              01 6b
255.255.255.255                              02 6b
192.168.1.255                                01 6b

Everything above seems ok, but...

cpu% cat /net/iproute
0.0.0.0         /96  192.168.1.254   4    none   -
192.168.1.0     /120 192.168.1.0     4i   ifc    0
192.168.1.0     /128 192.168.1.0     4b   ifc    -
192.168.1.9     /128 192.168.1.9     4u   ifc    0
192.168.1.255   /128 192.168.1.255   4b   ifc    -
127.0.0.0       /104 127.0.0.0       4i   ifc    -
127.0.0.0       /128 127.0.0.0       4b   ifc    -
127.0.0.1       /128 127.0.0.1       4u   ifc    -
127.255.255.255 /128 127.255.255.255 4b   ifc    -
255.255.255.255 /128 255.255.255.255 4b   ifc    -
2001:470:19:333:: /64  2001:470:19:333:: 6i   ifc    -
fe80::          /64  fe80::          6i   ifc    -
ff02::          /16  ff02::1         6m   ifc    0
ff02::1         /128 ff02::1         6m   ifc    0
2001:470:19:333:216:3eff:fe79:c0f7 /128
2001:470:19:333:216:3eff:fe79:c0f7 6u   ifc    0
fe80::216:3eff:fe79:c0f7 /128 fe80::216:3eff:fe79:c0f7 6u   ifc    0
ff02::1:ff79:c0f7 /128 ff02::1:ff79:c0f7 6m   ifc    0

I think, the above does not have any default route for IPv6 traffic.

After restarting Plan9, I attempted to try ipv6on script, but no luck :(

cpu% cat /lib/ndb/local
#
#  files comprising the database, use as many as you like, see ndb(6)
#
database=
	file=/lib/ndb/local
	file=/lib/ndb/common

auth=sources.cs.bell-labs.com authdom=outside.plan9.bell-labs.com

#
#  because the public demands the name localsource
#
ip=127.0.0.1 sys=localhost dom=localhost

ipnet=sebs.org.in ip=192.168.1.0 ipmask=255.255.255.0
	dnsdomain=sebs.org.in
	dns=192.168.1.3
	ntp=router
	smtp=router
	authdomain=sebs.org.in
	auth=auth

ip=192.168.1.2 dom=cto.sebs.org.in sys=cto
ip=192.168.1.3 dom=mon.sebs.org.in sys=mon
ip=192.168.1.9 dom=helix.sebs.org.in sys=helix
ip=192.168.1.254 dom=gw0.sebs.org.in sys=gw0

cname=helix.sebs.org.in dom=auth.sebs.org.in sys=auth
cname=helix.sebs.org.in dom=cpu.sebs.org.in sys=cpu
cname=mon.sebs.org.in dom=devel.sebs.org.in sys=devel
cname=cto.sebs.org.in dom=ftp.sebs.org.in sys=ftp
cname=mon.sebs.org.in dom=proxy.sebs.org.in sys=proxy
cname=mon.sebs.org.in dom=www.sebs.org.in sys=www

I can ping xen9 machine from all other machines on private LAN, but
can't ip/ping -6 any from xen9 :(

Whereas, all other machines, Ubuntu, Windows XP/SP3, FreeBSD and
Window-7 are getting IPv6 addresses automatically on a small/home
network from an instance of radvd-1:1.5-1 running on a Debian machine.

> It's not worth supporting any new 10Mb ethernet controllers,
> and new 100Mb ones are borderline.

--
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/      Visit: http://counter.li.org/