| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Question regarding user-mode and debugging terminals
> My partner and I are working to port an "educational"
> UNIX-like operating system from a custom simulator to
> the Xen platform for an operating systems class here
> at Brown University.
>
> Unfortunately, we're having quite a bit of difficulty
> switching the system into user mode. Currently, we're
> using borrowed code from an early linux kernel:
I'll leave this query to someone more familiar with the low level details!
> Second, students interacted with this OS (named
> "Weenix") through three terminals which were exposed
> to Weenix as character devices /dev/tty0 through
> /dev/tty3. Additional, the actual terminal through
> which the Weenix system had been started would serve
> as a console for printing "meta" debugging output to
> (this terminal would not be visible to Weenix itself).
>
> We've made significant ground porting Weenix to Xen
> (which we have renamed "Wox"), however, we're a bit
> hung up in trying to simulate those original three
> terminals without going overboard.
>
> We've toyed with the idea of simply using escape
> sequence to "split" a single terminal, but this seems
> ugly and is not truly what we'd like. We'd much prefer
> a way to attach multiple terminals to a single Weenix
> instance such that Weenix can interact with these
> terminals as if they were character devices.
The correct approach here if you want to add "real" terminals would be to
modify the Xen console framework to support them. Off the top of my head
you'd need to do something like:
1) modify the console backend and frontend drivers to understand the concept
of multiple terminals (with appropriate backward compatibility so as not to
break old frontends when they encounter a new backend - and preferably not
break old backends if they encounter a new frontend).
2) modify Xend to configure multi-console operation so that the back and front
ends know what they're doing
3) modify console daemon to handle multiple consoles per guest and provide a
means for user to connect
4) modify xm command syntax to handle connecting to multiple consoles per
domain
5) invent a sensible config file format for it all
6) (optionally) make this play nicely with multiple virtual serial consoles
for HVM guests - not required for your patch, and (I'd imagine) not required
for patch inclusion either.
I'd say that none of this is really fundamentally difficult, there are just
lots of things you'd need to hack on / tweak / fiddle with. Lots of
small-to-medium changes all over the tree. But it is something that we've
wanted for a while - it's been on the roadmap as an "Wouldn't it be nice...?"
for ages.
This list would probably be able to give you some support if you wanted to do
this, but obviously completing your own project has higher priority than
improving ours ;-) Still, if the two happen to coincide...
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home