Re: [JOS-Kernel] Device as a digital resource

[Gilbert Carl Herschberger II]

Thank you so much for your contribution to this discussion. Before this, I
couldn't see how devices and the I/O streams are very much alike. After all
this, one multiple stage object factory *is* the same as any other.

I put all devices under a device: scheme. Individual devices should be
sub-schemes, right? Here is one subscheme I would like to try:

"device:ram:?size=0xFF"

and

"device:ram:?start=0x0CC00&end=0xCCFF"

and

"device:ram:?start=0xCC00&size=0xFF"

In Java, this URI might return a byte array. Since memory is a limited
digital resource, it can be used if no other process is using it. If any
part of memory start to finish has already been allocated, the device
factory must return null.

At 12:29 AM 3/20/00 +0200, Al <[EMAIL PROTECTED]> wrote:
>Actually, this could be even better... The above URI point to the serial
>port, not the device *attached* to the serial port. Why not use this,
>instead:
>
>modem:device://localhost/ports/serial/1/attached?maxspeed=...
>
>Take note of the alternating modem:device beginning of this URI...

I understand your point. There must be symetry between the schemes and the
kind of objects it can produce. If we are creating a serial port, we should
have a serial port subscheme. From previous experience with the global
nature of URIs, I would put this whole discussion under a device: scheme.
It might be something like this:

port://localhost/ports/serial/1/attached?maxspeed=...
and
modem:port://localhost/ports/serial/1/attached?maxspeed=...

or

device:port://localhost/ports/serial/1/attached?maxspeed=...
and
device:modem:port://localhost/ports/serial/1/attached?maxspeed=...

While working on the Smart API for I/O streams, I discovered a powerful
concept of scheme chaining. Let me explain it here from a classic example.
To create a buffered, data input stream, we typically write code something
like this:

  public void example1() {
    String n = "example.txt";
    FileInputStream is = new FileInputStream( n );
    BufferedInputStream bis = new BufferedInputStream( is );
    DataInputStream dis = new DataInputStream( bis );
  }

>From the first release of the Smart API, it supported scheme chaining, or
putting schemes together by repeatedly going back to the factory. Scheme
chaining is both powerful and flexible. It gets a program exactly what it
wants in a very dense URI. This is the Smart API equivalent for example1():

  public void example2() {
    URI uri = new URI( "in:data:buffer:file:example.txt" );
    DataInputStream dis = (DataInputStream) uri.getObject();
  }

The in: scheme directs a request to the input stream factory. Each scheme
in the chain recursively uses the input stream factory. An input stream
factory returns any class derived from java.io.Inputstream. Subschemes know
how to convert from InputStream to the desired type.

"in:file:example.txt" -> InputStream (FileInputStream)
"in:buffer:file:example.txt" -> InputStream (BufferedInputStream)
"in:data:buffer:file:example.txt" -> InputStream (DataInputStream)

Likewise, I have become convinced that scheme chaining would work with
devices. If one scheme expects a certain kind of interface from another
scheme, we can use scheme chaining.

"device:port:/ports/serial/1" -> Port (SerialPort)
"device:modem:port:/ports/serial/1" -> Modem (USRoboticsModem)

>If the JOS specific interpreter of these URI's is told that the "modem:"
>protocol means "turn the object returned from device: into an object of
>type jos.devices.Modem" then this would work.

With scheme chaining, the "modem:" protocol means exactly that. It does
whatever it takes to convert the object created by the chain into an object
that implements "jos.device.Modem".

>Thus, for a VERY custom device, you could use this:
>
>com.mycompany.devices.CardioPulseMeter:device://localhost/...
>
>of you can set up and use custom drivers:
>
>com.3com.modems.56KVoiceFaxModem:modem:device://localhost/...
>
>What do you think?

Yes, something like that. Potentially, a subscheme can accept an arbitrary
class name and figure out the necessary conversion. On the other hand, we
have to return an object. This is an object factory. It returns an instance
of java.lang.Object or null. After it is created, an object must be cast to
an appropriate type.

  public Object getObject();

For example, special features of a 3com driver won't work with a Hayes
modem. If you really want to use the special features of
com.3com.modems.56KVoiceFaxModem, you might need to use the instanceof
operator, like this:

URI uri = new URI( "modem:port://localhost/ports/serial/1" );
56KVoiceFaxModem modem = (56KVoiceFaxModem) uri.getObject();

>> Since more types of devices than modems can be attached to the serial
>> port, the device manager can only return the raw version of the
>> device: the port itself.
>
>That is only if you wish the URI to return a fully expressed device. You
>may have defined protocols such as "modem:" that knows to convert the
>device attached to the port into a modem object, and you may just have a
>simple, raw device, which you can query, and then determine what it is.
>But you should also have access to the port itself, independently. For
>example, if I wish to set the maximum speed for the serial port, I have
>to tell this to the serial port, *not* the attached device...

Hmm. This crosses over to system information. This is a good idea. It might
be possible for many processes at the same time to query the device
subsystem. Opening a device for exclusive use is not the only possible
function of a device factory. How do you find out the maximum speed of
serial port 1? How do you find out what is really attached to serial port 1?

The ports themselves are detected by JOS at start-up. The system-wide
configuration of a JOS machine must explain to JOS what it is exactly
that's attached. Where does the system-wide configuration come from? You
can type it in manually. That is the classic way. You can run a probe to
let the machine try to figure out what is attached. A probe does not have
to be build into an operating system. It only needs to show you what you
need to type in manually. A modem probe can be sold separately.

>> To get at the raw serial port, you might use a URI like this:
>> 
>> device:serial://localhost/ports/serial/1/?maxspeed=...
>
>Once again, I think "serial:" should be *before* "device:" But anyway:

I think device: should be a major scheme. I start a device URI with device:
to keep it separate from other major URI schemes like desktop:, fpt:,
http:, in:, out: jdbc:, mailto:, x-registry:, applet: and servlet:.

>In this case, every "sub directory" of the URI will in reality also
>signify a protocol. Such as:
>
>com.custom.CustomModem:modem:serial:device://localhost/ports/serial/1/attac
hed?maxspeed=...
>

I don't understand.

>> Starting with interfaces we have already named:
>> 
>> ParallelPort
>> SerialPort
>> Modem
>
>We can post a list of proposed device names, and have people comment on
>device names which they don't like, while also adding their own proposed
>device names. These device names should be as general as possible, and
>should follow the typical class naming schemes we have accepted in JOS a
>(or two?) year ago. Something like starting with a capital, using full
>words, etc..

Excellent idea!

>Things like:
>
>Keyboard?keycount=104&functionkeys=true&layout=us-ascii
>PointingDevice?commandcount=4
>Mouse?buttoncount=3&wheel=true
>ISDNAdapter?lines=2&dataline=true
>EthernetAdapter?baud=100&encrypted=true
>Monitor?toomanyparameters=very_true  :)
>etc..

And maybe RAM, MemoryManager, DMAChannel, Floppy, CDROM, GraphicsTablet,
LightPen, TouchScreen.

>An apparent issue is: do we add the word "Device" after these things?

When these interfaces are already part of the org.jos.device package,
adding the word "Device" is mostly redundent and, in general, should not be
used. Exceptions are allowed, such as PointingDevice.

>> Like any smart factory, it must use a separate plug-in controller for
>> each sub-scheme.
>
>Apparently... Any piece of software must come in changeable modules. If
>that cannot happen, it has the fate and performance of things like
>Solaris, Windows, OS/2, etc... Look at Linux: everybody can put his
>little piece inside, and thus everybody (almost, other story) is happy.

Plug-ins are a good thing. Never before has an operating system had so many
plug-ins as JOS. The general Java architecture makes everything a plug-in.

>What happens if the Modem is on a PCI slot? Maybe the modem should not
>be responsible for knowing what port it's attached to, rather, the port
>knowing what modem is attached to it?

We have to throw system-wide configuration into this somewhere. JOS doesn't
know for sure it has a PCI slot until start-up. If it depends on a
persistent system-wide configuration, that might expect to find a modem on
a PCI slot. If it probes for a modem, that might find a modem on a PCI
slot. If JOS known that it's a modem, I should be able to tell it manually
and use the modem without restarting my computer.

As a diagnostic tool, I look forward to using the Universal Browser with
the device: scheme. It looks like we can create a Device Browser. I should
be able to type in "device:port:/ports/serial/1" and my browser should show
me (1) if it exists, and (2) its current status. For example, I should be
able to use a browser to quickly determine which process (if any) is
currently using my modem.


_______________________________________________
Kernel maillist  -  [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel