RE: [9fans] port/devcons.c is not port-able

RE: [9fans] port/devcons.c is not port-able

[Geoff Collyer]

Andrey has kindly put up the USB documentation at

	http://pages.cpsc.ucalgary.ca/~mirtchov/p9/usb

under which you can find the individual PDF files.
Or you can fetch the whole thing (~15MB) as

	http://pages.cpsc.ucalgary.ca/~mirtchov/p9/usb.tgz

The documentation includes the [UOE]HCI interface specifications and
the USB 1 and 2 protocol specifications.

Re: [9fans] port/devcons.c is not port-able

[boyd, rounin]

> A friend of mine just pointed out - we need all this legacy-free stuff for a
> port to the xbox ;)

it'll be an ex-box after i'v chucked it out the window.

RE: [9fans] port/devcons.c is not port-able

[Geoff Collyer]

I fetched all the documents cited in the initial block comments of the
openbsd kernel's *hci* source files, which should be descriptions of
the *HCI interfaces and the USB protocol definitions.  I'll try to get
them to Andrey for distribution on the web later today.

RE: [9fans] port/devcons.c is not port-able

[Frank Palazzolo]

A friend of mine just pointed out - we need all this legacy-free stuff for a
port to the xbox ;)

No serial/parallel/ps2 ports - only USB.  It would make a cheap terminal,
however.

-Frank

RE: [9fans] port/devcons.c is not port-able

[Charles Forsyth]

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

honestly, it's not so bad, especially compared to the average pc
parallel port interface (which one??, and just how DO your uart's fifos work):
i'm sure USB just needs a little elbow grease.
and copious spare time.

[-- Attachment #2: Type: message/rfc822, Size: 2842 bytes --]

From: "Frank Palazzolo" <palazzol@comcast.net>
To: "'Fans of the OS Plan 9 from Bell Labs'" <9fans@cse.psu.edu>
Subject: RE: [9fans] port/devcons.c is not port-able
Date: Wed, 14 Jul 2004 16:19:39 -0400
Message-ID: <001601c469df$e53425c0$1600100a@Frank>


A friend of mine just pointed out - we need all this legacy-free stuff for a
port to the xbox ;)

No serial/parallel/ps2 ports - only USB.  It would make a cheap terminal,
however.

-Frank

Re: [9fans] port/devcons.c is not port-able

[Charles Forsyth]

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

actually, although i thought it could have been better
in many ways, i didn't think USB-the-protocol was all that  bad.
the class/subclass/proto from the start was obviously going to
go the way of most global numbering systems, but the real
difficulty was the strange hardware/software interface produced
to drive it.  it was differently strange for everyone.
ambiguities in the standard as regards the nature of endpoints
didn't help.   i wonder if we ever make progress.
now, of course, it would have a SOAPy web services enabled
interface accessed by jakartatomcataxis servers in sillycon.

[-- Attachment #2: Type: message/rfc822, Size: 3263 bytes --]

From: ron minnich <rminnich@lanl.gov>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] port/devcons.c is not port-able
Date: Wed, 14 Jul 2004 13:42:53 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0407141342210.9223-100000@maxroach.lanl.gov>

On Wed, 14 Jul 2004, Dan Cross wrote:

> ron minnich <rminnich@lanl.gov> writes:
> > The keyboard-less, vga-less, serial-less nodes are all blades at this
> > point.  [[some not sold yet ]]
>
> Oo! Oo!  Do they have USB??  Okay, I'm going back into my corner now.

sadly, yes. Vendors like that usb stuff for some reason.

It makes my brain hurt, watching the gyrations of people trying to
write boot code for USB dongles.

ron

Re: [9fans] port/devcons.c is not port-able

[ron minnich]

On Wed, 14 Jul 2004, Dan Cross wrote:

> ron minnich <rminnich@lanl.gov> writes:
> > The keyboard-less, vga-less, serial-less nodes are all blades at this
> > point.  [[some not sold yet ]]
>
> Oo! Oo!  Do they have USB??  Okay, I'm going back into my corner now.

sadly, yes. Vendors like that usb stuff for some reason.

It makes my brain hurt, watching the gyrations of people trying to
write boot code for USB dongles.

ron

Re: [9fans] port/devcons.c is not port-able

[boyd, rounin]

> Oo! Oo!  Do they have USB??  Okay, I'm going back into my corner now.

otherwise we'll give you a shit-detail, private.  ;)

Re: [9fans] port/devcons.c is not port-able

[Dan Cross]

ron minnich <rminnich@lanl.gov> writes:
> The keyboard-less, vga-less, serial-less nodes are all blades at this
> point.  [[some not sold yet ]]

Oo! Oo!  Do they have USB??  Okay, I'm going back into my corner now.

	- Dan C.

Re: [9fans] port/devcons.c is not port-able

[boyd, rounin]

> weirdly enough, I've used ethernet consoles on linux for a while (UDP
> however) and you can have fairly amazing levels of oops that you can get
> out over the network ...

now, IL is a RDP so you could have a machine(s) somewhere that grabbed
console messages over IL and wrote them somewhere.

oh dear, this is sounding like syslog.

Re: [9fans] port/devcons.c is not port-able

[ron minnich]

On Wed, 14 Jul 2004, Dave Lukes wrote:

> Problem is, when there's a "panic: smashed stack" type condition,
> after that, the only complexity that matters is the complexity of the
> code path leading to the characters becoming humanly visible.

weirdly enough, I've used ethernet consoles on linux for a while (UDP
however) and you can have fairly amazing levels of oops that you can get
out over the network ...

> <thought> Is there any space in nvram where one could dump the last N
> bytes of console output? At least that way you'd be able to see it
> eventually ...

you have a hard limit on rewriting flash. There's no NVRAM big enough for
the messages. Life sucks.

> Of course, what would be cool would be a "panic display": an lcd with
> some nvram that keeps the last message in it.

not a good idea for 1024+ ondes ...

ron

Re: [9fans] port/devcons.c is not port-able

[boyd, rounin]

> being able to set consoles in plani.ini to console=+/tcp/host/875
> sounds like it adds flexibility ...

sure, but, as geoff said, i don't like the failure modes.

stuffing the last n lines of 'console' output to grab on
reboot might solve the failure mode issue, but you'll
need somewhere to stick it and a guarantee it'll
get there.

of course linux have already broken this because
the 3 zillion lines of output on reboot will probably
overflow any 'reasonably' sized 'place'.

Re: [9fans] port/devcons.c is not port-able

[Dave Lukes]

Problem is, when there's a "panic: smashed stack" type condition,
after that, the only complexity that matters is the complexity of the
code path leading to the characters becoming humanly visible.

I tend to agree with (?jmk?) that serial lines and terminal servers are
the way to go for the moment:
the serial line gets the bits easily out of the danger zone (the dying
machine),
and you can then log them at leisure.

As to the future, I'm sure that we'll all have USB consoles in a few
years.  Oh, joy.

<thought>
Is there any space in nvram where one could dump the last N bytes of
console output?
At least that way you'd be able to see it eventually ...

Of course, what would be cool would be a "panic display": an lcd with
some nvram that keeps the last message in it.
</thought>

DaveL.

matt@proweb.co.uk wrote:

>Hi Ron,
>
>I thought it sounded like a good idea it's just not something I feel qualified to comment on
>
>being able to set consoles in plani.ini to console=+/tcp/host/875
>sounds like it adds flexibility while, if your coding assumptions are correct, it reduces complexity elsewhere
>
>m
>
>

Re: [9fans] port/devcons.c is not port-able

[ron minnich]

On Wed, 14 Jul 2004 matt@proweb.co.uk wrote:

> I thought it sounded like a good idea it's just not something I feel
> qualified to comment on

well, that's enough for me, I'll prototype it under Xen :-)

ron

Re: [9fans] port/devcons.c is not port-able

[ron minnich]

On Tue, 13 Jul 2004, Geoff Collyer wrote:

> > There are machines that don't have keyboard, uarts, or vga coming out now.
>
> Maybe I (we) should finally read ericvh's paper on Console Over
> Ethernet (actually over TCP) from a Usenix ago:
> http://www.usenix.org/events/usenix03/tech/freenix03/full_papers/kistler/kistler_html/.

I don't have the model number of the HP machine without serial, I put it
back in the box when I realized what a headache it would be.

The keyboard-less, vga-less, serial-less nodes are all blades at this
point.  [[some not sold yet ]]

ron

Re: [9fans] port/devcons.c is not port-able

[matt]

Hi Ron,

I thought it sounded like a good idea it's just not something I feel qualified to comment on

being able to set consoles in plani.ini to console=+/tcp/host/875
sounds like it adds flexibility while, if your coding assumptions are correct, it reduces complexity elsewhere

m

Re: [9fans] port/devcons.c is not port-able

[Geoff Collyer]

Looks like this is a job for LinuxBIOS (serial port emulation per
future directions in the paper), so back to you, Ron!  ☺

Re: [9fans] port/devcons.c is not port-able

[Geoff Collyer]

> There are machines that don't have keyboard, uarts, or vga coming out now.

Maybe I (we) should finally read ericvh's paper on Console Over
Ethernet (actually over TCP) from a Usenix ago:
http://www.usenix.org/events/usenix03/tech/freenix03/full_papers/kistler/kistler_html/.

Ron, can you cite model numbers of the sorts of machines you're taking
about?

Re: [9fans] port/devcons.c is not port-able

[Skip Tavakkolian]

>> i think one must do something really outrageous to elicit reaction on
>> this list nowadays.  silence isn't necessarily discouraging, just a
>> sign that either nobody cares or they've all gone to the beaches of
>> california.
>> 
> 
> or are running MacOS :-)

ron 1 : rob 0

☺

Re: [9fans] port/devcons.c is not port-able

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

Kenji Okamoto <okamoto@granite.cias.osakafu-u.ac.jp> writes:
>
> > or are running MacOS :-)
>
> Because it comes with no sources? ☺

Not true!  You can get the sources to MacOS X.  Well, most of them
anyway.  I suppose it is technically true, though, as you have to go
get them seperately: they don't come with the system.  :-)

	- Dan C.

(ps- Nemo is Dr. Evil: ``I will call it, `The Allen Parson Project!' '')

Re: [9fans] port/devcons.c is not port-able

[Dan Cross]

andrey mirtchovski <mirtchov@cpsc.ucalgary.ca> writes:
> i think one must do something really outrageous to elicit reaction on
> this list nowadays.  silence isn't necessarily discouraging, just a
> sign that either nobody cares or they've all gone to the beaches of
> california.

There are beaches in California?  Oh, that's what the Mojave desert is!

Surfs up, dude!  If I grab my board and start running for the water, I
should make it in ... about three days.  I guess the tide will have gone
out by then.

Random Boydism:  God, I hate this state.  ``UA, I wanna go home!!''
(Reaches....)

	- Dan C.

Re: [9fans] port/devcons.c is not port-able

[Dan Cross]

Maybe this is relevant, maybe not.  My brain's been shot (uhh, not
literally for anyone who might wonder about that statement) over the
last few months so bear with me.

I have a digital camera that uses the mass storage protocol over USB.
I looked briefly at writing a driver for it, but realized at one point
that I would have to duplicate a lot of code to speak, e.g., the SCSI
protocol over USB to talk to it.  It occured to me that one way to deal
with it might be to write a SCSI loopback device that would speak the
SCSI protocol to/from a file descriptor that was passed into it somehow
(say by mounting it on one).  Then a user-level program could provide a
transport over say USB and let something above it talk SCSI so it would
still look like a disk as far as the rest of the system was concerned.

As for console input, we already have a console input file, right?  Or
at least a keyboard input file that effectively emulates a console
input file.  Can't we just cat whatever into that file to provide
console input from multiple sources?  E.g., cat /dev/eia0 > /dev/kbdin
(possibly parsing what comes out of /dev/eia0 to look for latin1()
style key sequences.  Perhaps it's time to look at pulling latin1() out
of the kernel and plonking it into libc again.  Everything that needs
to do alt sequences uses it, why is it still in the kernel?  But I
digress).  That is, just put the loopback in userland where it
belongs.  I think you're trying to get at something more subtle,
though, and I'm probably missing the point.

	- Dan C.

Re: [9fans] port/devcons.c is not port-able

[Kenji Okamoto]

> or are running MacOS :-)

Because it comes with no sources? ☺

Kenji

Re: [9fans] port/devcons.c is not port-able

[ron minnich]

On Wed, 14 Jul 2004, Kenji Okamoto wrote:

> > I would actually be making the whole thing simpler
>
> Actually I didn't understand why you needed that modification.
> Because of porting the system to another?

the devices in port/devocns.c are hardcoded to assume that there's a
keyboard, a uart, a vga console in some form or another. There are queues
and pointers in there that get initialized in random places. Random
different devices initialize (or don't) those variables to enable
different kinds of console I/O.

I understand the pragmatism, but it's a jungle in there.

There are machines that don't have keyboard, uarts, or vga coming out now.
port/devcons.c is living on borrowed time and we need to do better.

ron

Re: [9fans] port/devcons.c is not port-able

[Kenji Okamoto]

> silence isn't necessarily discouraging, just a
> sign that either nobody cares or they've all gone to the beaches of
> california.

Or this is the habbit of this list.  I can rmind many cases with no reaction
when someone posted I made something and put it there. ☺

Kenji

Re: [9fans] port/devcons.c is not port-able

[ron minnich]

On Tue, 13 Jul 2004, andrey mirtchovski wrote:

> > I would actually be making the whole thing simpler, but judging by (lack
> > of) reaction my idea did not get a good response.
> >
>
> i think one must do something really outrageous to elicit reaction on
> this list nowadays.  silence isn't necessarily discouraging, just a
> sign that either nobody cares or they've all gone to the beaches of
> california.
>

or are running MacOS :-)

ron

Re: [9fans] port/devcons.c is not port-able

[ron minnich]

On Tue, 13 Jul 2004, Geoff Collyer wrote:

> It's just not the amount of mechanism at issue, but the odds of a
> panic message or other serious complaint being seen, for instance.  If
> you've got console prints going only to a pipe, and the process
> reading the pipe blocks, for a while prints will go into pipe
> buffering (and not be seen) and then finally kernel processes doing
> prints will start to block when the pipe buffering fills.

yes but ... it was not just a pipe. The thing I was proposing was to allow
multiple console devices while
- removing the hardcode junk that is in there now (What happens
  when you have a machine with NO uart and NO display -- I have
  some now -- simple -- no console output). port/devcons.c is no longer
  portable.
- avoiding the hellish Linux 'structs with lots of initialized pointers'
  since in Plan 9 you can just do a namec() and get to the device
  that way.

So using a pipe did not at all rule out using a serial port, AND a window,
AND a tcp connection, AND vga if you were that crazy.

Anyway, I'll stop talking and at some point try to implement it.

> The current devcons is messy but pragmatic.  Plugging your serial
> consoles into a console server gives you remote access to the consoles
> and logging.

asuming you have a serial console. I have an HP K8 node with no serial
console at all. This is going to be the common case soon -- those serial
connectors are huge, require odd voltages, and vendors want them to go
away.

ron

Re: [9fans] port/devcons.c is not port-able

[Kenji Okamoto]

> I would actually be making the whole thing simpler

Actually I didn't understand why you needed that modification.
Because of porting the system to another?

Kenji

Re: [9fans] port/devcons.c is not port-able

[andrey mirtchovski]

> I would actually be making the whole thing simpler, but judging by (lack
> of) reaction my idea did not get a good response.
>

i think one must do something really outrageous to elicit reaction on
this list nowadays.  silence isn't necessarily discouraging, just a
sign that either nobody cares or they've all gone to the beaches of
california.

Re: [9fans] port/devcons.c is not port-able

[Geoff Collyer]

It's just not the amount of mechanism at issue, but the odds of a
panic message or other serious complaint being seen, for instance.  If
you've got console prints going only to a pipe, and the process
reading the pipe blocks, for a while prints will go into pipe
buffering (and not be seen) and then finally kernel processes doing
prints will start to block when the pipe buffering fills.

Actually, the panic case is worse: the message would go into pipe
buffering, and no matter what the reading process is doing, the system
will shut down and the reading process is unlikely to run (or run for
long enough to matter), and again the message wouldn't be seen.  So
the user experience of a panic in that case would be either a
mysterious hang of the entire system or a sudden blanking of the
screen and a reboot, possibly both (the hang, a delay and a reboot).

The current devcons is messy but pragmatic.  Plugging your serial
consoles into a console server gives you remote access to the consoles
and logging.

Re: [9fans] port/devcons.c is not port-able

[ron minnich]

On Tue, 13 Jul 2004, Geoff Collyer wrote:

> I believe that the idea of console printing (if not input) is that the
> mechanism should be simple so that when the system is in trouble, it
> can still get a message out about the nature of the trouble.  So the
> more mechanism needed to get characters printed, the less likely that
> goal is to be achieved.  In particular, you'd really like the kernel
> to not block for long waiting for console output.  Admittedly there's
> a fair bit of mechanism already.

I would actually be making the whole thing simpler, but judging by (lack
of) reaction my idea did not get a good response.

Ah well, that console code is still a bit messy.

ron

Re: [9fans] port/devcons.c is not port-able

[Geoff Collyer]

I believe that the idea of console printing (if not input) is that the
mechanism should be simple so that when the system is in trouble, it
can still get a message out about the nature of the trouble.  So the
more mechanism needed to get characters printed, the less likely that
goal is to be achieved.  In particular, you'd really like the kernel
to not block for long waiting for console output.  Admittedly there's
a fair bit of mechanism already.

If only every PC came with a DECwriter attached as its console device. ☺

[9fans] port/devcons.c is not port-able

[ron minnich]

working with Xen has convinced me that devcons.c is not totally portable.
The key problems are assumptions that certain devices are there, such as a
uart.

Also, there is the
	/*
	 *  how many different output devices do we need?
	 */

comment, which leads me to believe whoever wrote it was thinking that all
the permuations of devices for devcons were getting out of hand.  There
are a lot of cases in there.

Your kernel has to define some symbols it might not really want to. If you
don't have a uart, what do you do about uartputs? You have to define a
dummy of course.

So I got to wondering: what if we used the fact that namec is so simple
and easy in the kernel? Define the following two files in devcons.c:
consout
consin

Let me take the case of consout first. If you write this:
+file
to consout, devcons driver does a namec of 'file' and adds it to the list
of files it writes to when it does output. So, e.g.,
echo +/dev/eia0 >>/dev/consout

will add serial output for console output. Of course it can go to a file:
echo +/log/console >>/dev/consout

or a socket:
echo +/net/tcp/blahblah >>/dev/consout (console logging to a remote machine)

or a window you want:
echo +/dev/wsys/9/cons >>/dev/consout
console output goes to the window of your choice (try doing that in X!)

or a pipe or whatever.

to remove a file that is used as console output
echo -file >>/dev/consout

you can select some devices:
cat /dev/consout | sed '/eai0/s/\+/-/' > /dev/consout
eliminates console output to eia0

Now, we've got a really portable console output design. You can do the
initial setup in main() in the kernel, you remove all the special cases,
and you don't need special things like uartputs in devcons.c

OK, what about input? I don't know. The multiple output case is easy to
do, the input case I don't understand in all variants due to the use of
interrupts for console input devices. I don't know how to hook them up.

Currently, as interrupts happen on (e.g.) /dev/eia0, there is a callback
(what else to call it?) that is provided by /dev/console to buffer up the
characters and lower interrupt overhead. The driver for a console device
has to know it is a driver for a console device, and it has to call the
right thing in devcons. You get multiple console devices by making sure
that each device that *might* be a console knows to call one of several
console handlers from their own interrupt handler (I have the Xen stuff
call echo()). Unlike almost everything else in Plan 9, you can't really
use any random file for a console.

So:
echo +/dev/eia0 >>/dev/consin
echo +/dev/xencons >>/dev/consin

is not going to work, since xencons might be a socket.

So does that kill this whole idea, or is there a way to do it, or is it
just a bad idea?

ron