Ah, the lurker returns... Please pardon my ramblings.
>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.
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?
In this respect, the individual scheme specifies several things:
1. The class which is returned (which must be a subclass/interface of
Device)
2. If it's a limited resource, then a null may be returned if the resource
has already been allocated.
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.
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.
Don't get me wrong. This feels to me to be one of the best solutions to
device allocation I've seen.
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?
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).
>>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.
Here we come down to how much configuration of the device should be done by
the programmer, as opposed through internal setup. Does the programmer
really need to know whether modem A is on a serial port or a USB port? The
programmer should be able to find all the modems, and discover what are
their properties (such as maximum speed, and various possible bit settings
- I've known some bad modems in my day that could only be set to
odd-parity), and then select the best fit. Another possibility would be to
send a template to the device:modem scheme for it to return the best fit.
We must not go overboard on this URI schema. We need to keep it simple.
Would you want to have to type in
"in:data:buffer:file:fat16:hdd://1?cylinders=255&tracks=65535&file=external.txt"?
The "file:" scheme automatically maps the given file to the internal
device registry, whether the file be on a remote machine, a RAM disk, or on
a hard-drive.
>
>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.
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.
-Matt
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
