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

[Gilbert Carl Herschberger II]

At 11:01 AM 3/21/00 -0600, [EMAIL PROTECTED] wrote:
>This means that now the device factory must handle the registration and
>allocation of *every* device.  Wouldn't it be easier, in that respect, to
>have the device schemes register themselves with "device:", then the
>individual schemes themselves handle the allocation?

A device factory is a smart factory, a factory that supports plug-ins. A
smart factory dispatches a request to individual plug-ins, called controllers.

A device factory corresponds to a major device: scheme. Each sub-scheme
must have its own controller. All of the URIs that start with device: are
dispatched to the device factory. In turn, the device factory dispatches a
request to each controller, until a controller returns an object (non-null)
or there are no more controllers.

This architecture is recursive. A device factory is a controller, too. It
plugs into the Smart API. The runtime configuration of the Smart API
becomes a tree of controllers.

Plug-in are added through custom configuration. The whole Smart API is
future-oriented. Any URI scheme imaginable can be plugged into the Smart
API if it implements the well-known Controller interface.

>In this respect, the individual scheme specifies several things:
>
>1. The class which is returned (which must be a subclass/interface of
>Device)

Exactly! Each scheme, controlled by a controller, specifies which class(es)
are returned by the scheme. The class: scheme always returns an instance of
java.lang.Class (or null).

class:java.awt.Button -> java.awt.Class

A schemes might return instances of more than one class. The object: scheme
returns an instance of *any* class:

object:java.awt.Button -> java.awt.Button

>2. If it's a limited resource, then a null may be returned if the resource
>has already been allocated.

Null is returned for any number of reasons, such as (1) a limited resource
that has reached its limit, (2) a non-sensical request (malformed URI), (3)
a controller is missing, or (4) an inappropriate request as determined by
security.

Imagine a scheme that allows up to five simultaneous TCP/IP connections.
When a program requests the sixth connection, null is returned instead.

The jdbc: scheme has been implemented in the Smart API. If you use a jdbc:
URI, you'll get an instance of java.sql.Connection (or null).

The Smart API is backward compatible. Imagine asking for a jdbc: connection
while using a virtual machine from Java 0 (JDK 1.02). Don't worry. The
Smart API does not crash. The controller for the jdbc: scheme cannot be
instantiated at all because the java.sql package is missing. Every jdbc:
request is denied because its controller is missing.

You can have anything you want. The device factory is a plug-in. It is
optional. Imagine you come to distrust the device: scheme entirely. You
can't get it to work in your environment. Simply re-configure the Smart API
to skip the device factory. Every device: request is denied because its
controller/factory is missing.

>But wouldn't it be "nicer" if, instead of returning null, it returns an
>error message describing what's wrong with the request, such as "out of
>bounds memory allocation", or "XYZ has already allocated that resource",
>and so on.

For BCNI and Smart API, no exception should be thrown by a controller or
factory. This has been a difficult architectural decision. In a multiple
stage factory, null can be returned much faster than an exception. Throwing
an exception complicates every Smart API interface. It complicates
interprocess communication.

A smart factory is optimistic. It uses the getObject() method exclusively.
It does not use acceptURI() to find a controller. From the first controller
installed to the last, a smart factory calls getObject() for each
controller until (1) an object is returned (non-null) or (2) there are no
more controllers.

>Also, how would one deallocate the resource?  Would this need to be
>specified in the finalize method of the resource's returned object?  What
>if the particular JVM that allocated this resource crashed, would the
>resource then be unavailable to everyone, requiring a reboot?  These
>questions aren't just limited to your particular implementation; they are
>serious things to consider for any system.

After a resource has been "opened" by the URI-based subsystem, we need a
corresponding way to "close" it. I expected that objects would implement a
close() method. The close() method cannot fail. This would be consistent
with work that has already been done on asynchronous I/O. (And a finalize()
method should invoke close().)

>Don't get me wrong.  This feels to me to be one of the best solutions to
>device allocation I've seen.

I agree. I like it for both political and technical merits. I like this as
a political solution because a loosely orgazized international group of
programmers can work in parallel on each sub-scheme and its corresponding
controller. It does not require centralized control over schemes,
controllers and their corresponding devices. It does not require a
standards body. It is a bazzaar, not a cathedral.

I like it as a technical solution because it is built to last. It has a
very long shelf life.

I like it because it is easy to develop. It is easy to build. We implement
something simple that works and build upon it. It is both backward
compatible and future-oriented. Any old scheme can expanded with new
features. Any new scheme can depend on existing ones.

I like it because it is flexible. The entire URI is a character array,
which easily passes through a persistence barrier. A URI is easy to store.
A URI is easy to enter at the keyboard. A URI is easy to pass from one
process to another.

>Some other things to consider.  How would a program discover which devices
>are available?  How would the admin then configure these devices so that
>they are setup correctly?  I.e. how would you tell
>"device:sound://localhost/1" to use DMA channel 1 instead of channel 3?
>Then again, how would you know that there aren't more than one sound card
>available on localhost?

Think about this: a search for URLs requires a search engine. It is not
feasible to ask the Internet for a list of all valid URLs. Likewise, a
local search engine would provide a human-readable list of matching device
URIs.

>Perhaps I'm looking at the problem in the wrong direction.  The URI here
>would be the way for the programs to allocate a resource.  Some other
>technique would be needed to discover the devices available, and possibly
>another to configure them (a bean resource would be very handy here).

I agree. We should be talking about two compatible mechanisms here. We need
a mechanism to discover and configure devices. We need another mechanism to
open an existing device.

>This may be a good place to add our diagnostic tools and configuration
>tools.  But how do we do this?  Do we add another scheme, such as
>"config:device:port:/ports/serial/1", or do we add it to the path:
>"device:port:/ports/serial/1/config"?  I dunno.

Yes! I like the idea of a config: scheme. There are always default
properties for a device. Default properties must be persistent. A config:
scheme interacts with a system-wide persisent data registry. To explain to
JOS that its IP address must be 5.5.5.120, you could ask for an IP
configuration object.

  public void example() {
    URI uri = "config:ip:";
    Configuration config = (Configuration) uri.getObject();
    config.setAddress( "5.5.5.120" );
  }

The IP configuration object must store its default properties somewhere.
That is what a system-wide registry and data registry interface is for.

  public void setAddress( String v ) {
    URI uri = "x-registry:system:/network/ip";
    PersistentRegistry r = (PersistentRegistry) uri.getObject();
    r.setString( "Address", v );
    r.close();
  }

When configuring a device through the config: scheme, such changes are
persistent. They will return even if you restart JOS.

Transient properties for a device are set through the device: scheme. These
properties are not persistent. They disappear as soon as you close a device.


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