> -----Original Message-----
> From: Todd L. Miller [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 04, 2000 4:18 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JOS-Kernel] Re: native console & bug report
>
> > I think that the object model for the consoles is fine for the consoles
> > themselves, but as soon as we try to add real shells to them, it won't
> work.
> > There isn't enough flexibility there. I'll see what I can come up with
> as I
> > continue to work with it.
>
> Not enough flexibility? setChar() would seem to allow you to
> build whatever flexibility you might want into a wrapper (text
> output-wise).
.
I'm looking on it from the viewpoint that there is a lot that a shell may
want to do with the screen that would be difficult to do on just a setChar()
and putChar() basis. The current implementation doesn't give access to the
keyboard (which you do below) to the individual consoles which would have to
hand it to the shells. The shells would also want to be able to change
screen colors, move the cursor about (and how is that done, BTW? Currently
the cursor just sits 3/4 down the screen on the native console and doesn't
show up at all in the Java consoles.), Page up/down and all over the place,
do text windowing (ala emacs), etc. A lot of this we'll get with the
JCurses library (which also doesn't deal with the cursor properly), but
there will be a bit of changes and additions that need to take place in
order to integrate that in. I guess my point was that we can't do that with
the current interface.
> w.r.t. unix-style piping, a consoleOutputStream class
> should be fairly easy to generate, i.e.:
>
> public class consoleOutputStream extends java.io.OutputStream {
> proctected console c;
>
> public consoleInputStream( console c ) {
> this.c = c;
> }
>
> public void write( int b ) {
> c.putChar( (char)b );
> }
> }
>
> and consoleInputStream only slightly more difficult:
>
> public class consoleInputStream extends java.io.InputStream implements
> KeyListener {
> protected keyboard k;
> protected Queue q;
>
> public consoleInputStream( keyboard k ) {
> k.addKeyListener( this );
> }
>
> public int available() { ... }
> public int read() {
> /* Queue's dequeue blocks, waiting
> for a character from keyTyped() */
> q.dequeue();
> }
>
> ... keyTyped( ... ) { ...
> q.enqueue(...);
> }
>
> }
>
> Ignoring login for the moment, a shell would be started like so:
>
> keyboard shellK = jos.system.keyboard.getKeyboard();
> console shellC = jos.consoled.getCurrentConsole(); /* has matching setCC,
> which also does not exist at the present time */
>
I'm not so hot on this approach. I'd prefer somehow that the shells are
told what console they get and when the keyboard is theirs. In the same
vein, I think there needs to be a Screen object which keeps control of the
mapped byte array. In short, anytime there is a scarce native resource,
there needs to be an object keeping track of it to make sure that we don't,
for instance, have multiple consoles ever trying to write to the screen at
the same time.
> shell theShell = new some_shell( shellK, shellC );
> theShell.start();
>
> /* end of init */
>
> or, if we're writing the shell as an application (e.g. static
> main()), which we should be:
>
> ClassLoader cl = jos.system.proc.getCleanClassLoader();
> Class jlSystem = cl.getClass( "java.lang.System" );
>
Well, there is some reflection stuff that goes here to make the following
work, but I get the idea. Really, though, this is the realm of JOSCore
(org.jos.core.*) and the process model. We can't really make this work
until that is in place.
> jlSystem.setIn( shellK );
> jlSystem.setOut( shellC );
> jlSystem.setErr( shellC );
>
> jos.system.proc.startProc( cl, cl.getClass( "org.jos.app.shell" ) );
>
> /* end of init */
>
> -- noting, of course, that jos.system.proc doesn't exist quite yet
> :) (Which also means that the interface sketched out above will probably
> change :))
>
> In either case, the shell could completely ignore the streams
> and go to a fully event-based system, where it subscribes on its own to
> the keyboard. (Where an xterminal would add, before startProc():
>
> jsK = cl.getClass( "jos.system.keyboard" );
> jsK.setKeyboard( myXKeyboard );
>
> jsCD = cl.getClass( "jos.system.consoled" );
> jsCD.setCurrentConsole( this );
>
> so that the correct keyboard/console would be found by the shell. As an
> aside, the shell could provide its own consoled whose console drivers just
> use get/setChar on a given othe console and their own buffer -- this would
> be suitable generic for any kind of console. Further thoughts: it might
> be worthwhile to move the currentConsole question out of consoled, and/or
> extend it in two ways: first, optionally ignore the Fx keys (and/or remap
> them), for single console situations; second, provide a class from which
> to generate new consoles in init() and/or provide a method
> init(console[]), where the initializer provides the desired mix of
> consoles.)
>
A lot of this I foresee being configurable off of the registry. It is
almost like there needs to be a single meta shell to intercept the Fx keys
and control the switching between shells. Hmmm.....
> (BTW, aviery, do you have CVS commit privs?)
>
> -_Quinn
>
I have a CVS account, but I don't think I have commit privileges on JJOS.
- Avery
> _______________________________________________
> Kernel maillist - [EMAIL PROTECTED]
> http://jos.org/mailman/listinfo/kernel
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
