At 11:30 AM 3/21/00 -0500, "Todd L. Miller" <[EMAIL PROTECTED]> wrote: > Okay, so there's another of level indirection in here that I >missed. That is, Controller.getObject() may well return itself, but the >Controller for a Device is the only object in the system which keeps a >driver reference?) So, there are two things going on here at the same time. As you point out, we misses a step. Indirection -- between a user process and a low-level device -- might be required because of class loaders and threads. Both class and class loader are significant in casting and using the instanceof operator. Carefullly consider the following snippet: public void example() { String s = "org.jos.device.Port"; Object o = Factory.getObject( s ); if ( !o instanceof Port ) { return; } Port p = (Port) o; : } If two class loaders are involved, this snippet will never work. A user process always has a custom class loader, so that classes used by a user process can be garbage collected when a process dies. The device factory is system-wide with its own custom class loader. A low-level device is guaranteed *not* to be on the same class loader as a user process. A user process always has its own thread, so that its bytecode can be interpreted asynchronously from all other threads. The device factory is part of the system process. A system process has its own thread. Each device might need to have its own private thread for double-buffered I/O. A high-level device runs off the user process thread. A high-level device communicates with a low-level device through inter-process communication (IPC). Inter-process communication is required to break through the persistence barrier that makes all processes independent. A low-level Port is created in a system process. The low-level device manager must make sure that only one low-level Port at a time for each port in hardware. An IPC channel is opened between this object and a high-level Modem created in a user process. A user process can do whatever it wants with the low-level Port through an IPC channel. In fact, the low-level port is a JVM-specific class. Any modem that uses a port is not a JVM-specific class. Therefore, there must be at least two packages for our JOS device project: decaf.device and org.jos.device Starting with org.jos.device, we should build generic device drivers that work with any distribution of JOS. Any JOS-specific application uses these generic device drivers. We would have a Port interface, etc. For the decaf virtual machine only, we would have decaf.device. A BCNI factory for decaf would return an instance of GenericPort when asked for a Port. When any device needs to use a serial port, it uses a serial port. Any device can use a serial port. Here is what a port and port listener might look like: // Port.java package org.jos.device; public interface Port { public int getID(); public PortListener getListener(); public void setListener( PortListener v ); public void run(); public void write( byte[] v ); public void close(); } // PortListener.java package org.jos.device; public interface PortListener { public void onRead( byte[] v ); public void onClose(); } Since a byte array passes easily through a persistence barrier, a generic port can be used by all kinds of devices. This is must better than anything I've seen from other operating systems. Here is my first attempt at a generic port: // GenericPort.java package decaf.device; public class GenericPort implements Port { GenericPort( int v ) { id = v; } public PortListener getListener() { return listener; } public void setListener( PortListener v ) { listener = v; } public void run() { synchronized( flag ) { flag = Flag.RUNNING; } for (;;) { synchronized( flag ) { if ( flag == Flag.CLOSED ) { break; } } for ( int i = 0; i < SIZE; i++ ) { int b = queue.read(); if ( b < 0 ) { if ( i == 0 ) { Thread.yeild(); break; } byte[] temp = new byte[ i ]; System.arraycopy( buffer, 0, temp, 0, i ); listener.onRead( temp ); break; } buffer[ i ] = (byte) i; } } } public void write( byte[] v ) { int iMax = v.length; for ( int i = 0; i < iMax; i++ ) { queue.write( v[ i ] ); } } public void close() { synchronized( flag ) { flag = Flag.CLOSED; } } private Flag flag = Flag.IDLE; private int id; private PortListener listener; private byte[] buffer = new byte[ SIZE ]; private EventQueue queue; } _______________________________________________ Kernel maillist - [EMAIL PROTECTED] http://jos.org/mailman/listinfo/kernel
Re: [JOS-Kernel] Device as a digital resource
Gilbert Carl Herschberger II Wed, 22 Mar 2000 09:03:41 -0800
- Re: [JOS-Kernel] Device as a digital resource Al
- Re: [JOS-Kernel] Device as a digital res... Gilbert Carl Herschberger II
- Re: [JOS-Kernel] Device as a digital... Al
- Re: [JOS-Kernel] Device as a dig... Gilbert Carl Herschberger II
- Re: [JOS-Kernel] Device as a... Al
- Re: [JOS-Kernel] Device... Gilbert Carl Herschberger II
- Re: [JOS-Kernel] De... Todd L. Miller
- Re: [JOS-Kernel] De... Al
- Re: [JOS-Kernel] De... Todd L. Miller
- Re: [JOS-Kernel] De... Al
- Re: [JOS-Kernel] De... Gilbert Carl Herschberger II
- Re: [JOS-Kernel] De... Al
- Re: [JOS-Kernel] De... Gilbert Carl Herschberger II
- Re: [JOS-Kernel] De... Todd L. Miller
- Re: [JOS-Kernel] De... Al
- Re: [JOS-Kernel] Device as a digital resource Matt . Albrecht
- Re: [JOS-Kernel] Device as a digital res... Al
- Re: [JOS-Kernel] Device as a digital... Gilbert Carl Herschberger II
- Re: [JOS-Kernel] Device as a digital res... Gilbert Carl Herschberger II
- Re: [JOS-Kernel] Device as a digital... Todd L. Miller
- Re: [JOS-Kernel] Device as a digital resource Matt . Albrecht