[9fans] THX hell

OK, here's a quandary.

THX is the tiny horrible xen, a little USB stick that I've got a
standalone system, AND a terminal you can boot from (e.g.) 9grid.net.
It has ballooned (firefox) to require a 2GB USB stick, but hey,
they're $15 at Fry's, who cares. You can boot it, it boots fine and
works fine on my T41.

It's nice, we don't even load X11, since we have Aki's FB drawterm.
Just load fbdev, good to go.

The goal here is to make Linux an insignificant part of the machine.
Boot Linux as dom0, but run Linux in (e.g.) 32MB, and give most of the
machine to Plan 9. Linux is a driver. Your immediate interface to Plan
9 is bash. There are no /etc/rc* scripts.

on my T60, there is no fbdev support. And you can't use vesafb. You
can't use vesafb in Linux, as the 16 bit part of linux never runs
under Xen. I would need to add vesafb support to Xen. This makes my
brain hurt.

I could add X11 to THX, and we could use drawterm-x11. This is not
really what we wanted to do, but ...

I was trying to have this ready to demo at BAP9UG, May 10, but this is
a snag! There is no easy FB support for T60, and I think this problem
will just become worse. Not being able to load vesafb is a problem.

So, choices:
1. Stick with Xen, add vesafb to Xen, done.
2. Stick with Xen, add X server to THX distro, run drawterm-x11, done.
3. Move to KVM, so we can have vesafb, use drawterm-fb, done.

any ideas here? What makes sense?

ron

> any ideas here? What makes sense?

4. Use the T41 instead.

On 5/1/07, Richard Miller <9fans@hamnavoe.com> wrote:[color=blue][color=green]
> > any ideas here? What makes sense?[/color]
>
> 4. Use the T41 instead.
>
>[/color]
yeah, but the goal here is to provide something others can use. So, I
reject (4) :-)

ron

In (3), are you suggesting plan 9 on kvm directly, or plan 9 on xen on kvm?

> 1. Stick with Xen, add vesafb to Xen, done.[color=blue]
> 2. Stick with Xen, add X server to THX distro, run drawterm-x11, done.
> 3. Move to KVM, so we can have vesafb, use drawterm-fb, done.
>
> any ideas here? What makes sense?[/color]

Doesn't KVM requires hardware virtualization? Also Xen is
supposedly faster on most benchmarks. Choice 2, while not
ideal, makes the most sense to me.

On 5/1/07, Bakul Shah <bakul+plan9@bitblocks.com> wrote:[color=blue][color=green]
> > 1. Stick with Xen, add vesafb to Xen, done.
> > 2. Stick with Xen, add X server to THX distro, run drawterm-x11, done.
> > 3. Move to KVM, so we can have vesafb, use drawterm-fb, done.
> >
> > any ideas here? What makes sense?[/color]
>
> Doesn't KVM requires hardware virtualization? Also Xen is
> supposedly faster on most benchmarks. Choice 2, while not
> ideal, makes the most sense to me.
>[/color]

That's what I decided too. yes, xen is 6x faster than kvm right now.
At the same time, I'm getting lots of input from folks in the business
that they expect kvm to win in the long run. But, for now, Xen is it.

I'm trying and failing to get X started in THX. X starts, but never
gets the keyboard. I think it's because the tty control is never
really started up. You can't do ctl-alt-f1, for example. Also, if I do
the magic sysrq sequence it works fine.

I hate to ask an X11 question here, but what would cause X not to be
able to grab keyboard?

ron

Ok,

Talking out of my hat completely but can you extract enough
of X11 to initialise the server and exit? maybe a main.c that
wraps around the initialisation code of an apropriate X11 VGA driver.

If you can do this then your fb drawterm could just map the
relevant bit of memory and draw in it, much like the plan9
vga driver.

If you got clever enough (wasn't somone working on pass-through
drivers for xen?) you could run a real plan9 terminal in another
xen VM and it could map the physical framebuffer offered
by Linux in dom0.

See? I told you I didn't know what I was talking about.

-Steve

well, I am close. X is now starting up -- you can NOT start X without
being able to run a keyboard compiler when it starts -- and xterm is
running, and doing this:
1201 write(2, "Failed to open input method\n", 28) = 28

which boils down to it can't find this:
1201 open("/usr/X11R6/lib/X11/locale/lib/common/xlibi18n.so.2",
O_RDONLY) = -1 ENOENT (No such file or directory)

which does not exist on my machine anyway. xterm does come up, and as
I type into it, the window size -- or the X display? -- changes quite
a bit -- it is changing resolution I suppose -- but no keyboard input
makes it to the app.

I had hoped 9term would work but it can't open /dev/pts/0, even
thought devpts is mounted. Some trick I am missing. It's weird running
linux without any rc scripts having been run. I have yet to use the
word fun, however.

it's interesting to run this stuff by hand, and just see what a tangle
web we have weave'd over 15 years. It's been a while since I watched x
apps this closely. Xterm opens about 50 libs, while failing to open
about 300.

ron

On 5/1/07, ron minnich <rminnich@gmail.com> wrote:[color=blue]
>
> it's interesting to run this stuff by hand, and just see what a tangle
> web we have weave'd over 15 years. It's been a while since I watched x
> apps this closely. Xterm opens about 50 libs, while failing to open
> about 300.
>[/color]

This would actually make a pretty great paper - detailing just how
much crap has built up and become interdependent over time.

-eric

Anthony Sorace wrote:[color=blue]
> you might talk to the Opera people. in addition to having a PC-type
> browser that runs on multiple platforms, they have slimmed-down
> versions that run on various embedded platforms. they've got a
> smallish version that runs on the Nokia N800 (a linux-based handheld
> device) which has decent performance and does ajax (i'm not sure what
> standards or test suites apply, but google mail and one other ajax-ish
> site i use work, which is all i really know about).
>
> they're not open source and i believe you'd have to get their approval
> for redistribution; not sure how that squares with any religious
> convictions.
> anthony
>[/color]

Opera is certainly worth a look, IMNSHO.

We've just stated shedding Firefox and SeaMonkey in favor of Opera.

Opera used to wear its feet on the wrong legs, UI-wise, but has become more
configurable, as well as better at handling the all-too prevalent badly-written
websites.

It builds faster and lighter from the *BSD ports tree than SeaMonkey or
Thunderbird, does not seem have their memory leaks or resource appetite on OS X
PPc versions.

Current license is not overly onerous, but a chat with them is certainly in order.

Bill