Gilbert Carl Herschberger II wrote:
> 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.
Have in mind that the URI's agive don't return a byte array, they return
a device object. I think you should alternate the protocols used.
Instead of:
device:ram://localhost/rambus?offset=0x0&length=0xFF
you want:
ram:device://localhost/rambus?...
And if you want that to return a byte array, you should also do this:
byte[]:ram:device://localhost/rambus?...
But if you are going to convert a device into a device of type RAM, then
you have to place the "ram:" protocol before the "device:" protocol,
just like zip files:
jar:zip:http://localhost/hda1/home/personal.jar
> 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.
Of course, this goes for example's sake only, e? I don't think arbitrary
memory access is exactly what we want in our security manifesto! :)
> 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)
I still think that the port should not be able to be converted into a
Modem. I think that the URI should end with /ports/serial/1/device? or
something equivalent, to distringuish it from the port itself.
> URI uri = new URI( "modem:port://localhost/ports/serial/1" );
> 56KVoiceFaxModem modem = (56KVoiceFaxModem) uri.getObject();
Yes, I really like this! This lets programmers tap into a device from
wherever in their code, and it lets the System handle things centrally
with stable and concentrated security. If there is not other way to
access a physical device on JOS (and virtual devices) other than the
Device interpreter, there is a lot of power behind. A lot of
manageability. This sound very nice...
> How do you find out the maximum speed of serial port 1?
There may be information in the chipset, the BIOS or the whatever. There
may be manual information by the user. Alas, there is the default and
safe assumption of 19200... There is no certain way really, not yet, and
definitely not with all existing serial ports.
> How do you find out what is really attached to serial port 1?
Same as above... You may guess that the PS/2 port connects to either a
Keyboard or a pointing device. You can search serial ports for modems
and null cables. You can search the parallel port for printers, cameras
and scanners. But you can't *always* know for certain what you are
dealing with. No possible way.
> The ports themselves are detected by JOS at start-up.
The devices attached to the ports could also be detected, if we have the
drivers for them. It depends. The more JOS, the more devices will be
detected. Other devices will not function until drivers are installed.
> I think device: should be a major scheme.
I see how you mean this. "device:" will not be treated like the rest of
the protocols, it will just signify that the rest of the protocols will
be "transformation" protocols of the returned object. The "device:" is
there just to help the system know that this URI is intended for the
device manager.
> 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.
Yeah, I see your point, but what about things like:
jos.system.security.JOSSecurityManager
We could leave out the "JOS" part, since it's in package jos., but it
would confuse programmers. Another example: JFrame could very well be
Frame, since it's not in the java.awt. package, but things are clearer
when that J is in front... The same could apply to JOS. I donno.
> The general Java architecture makes everything a plug-in.
Very true. With the capabilities of reflecting on interface class files,
I don't think there is actually a way to *stop* things from being
plug-ins! :)
> If JOS known that it's a modem, I should be able to tell it manually
> and use the modem without restarting my computer.
But this is JOS, not the modem... I don't think the Modem should know
where it is (PCI or serial), I think only the device manager should.
--
"Learn from others' mistakes, for you won't live long
enough to make them all yourself..."
________________________________________________________________________
[EMAIL: mailto:[EMAIL PROTECTED]] [URL: http://www.outworld.org/people/al]
[TEL1: (30) +31 422392] [TEL2: (30) +31 428154] [CELL: (30) +937 110247]
[ADDRESS: 14 Argonafton St., Kalamaria, 551 31, Thessaloniki, Greece GR]
PLEASE DO NOT SEND ME ANY UNSOLICITED COMMERCIAL EMAIL [DSS: 0xDBEF8ECC]
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
