> 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.
It should be possible, on the other hand, to generate an
error: scheme that returns the error/exception/problem associated with a
particular URI; it would be entirely optional for each Controller to
recognize error: requests that correspond to URIs for which it has
responsibility. The idea is similar to UNIX's errno. e.g. you start at
the root of the tree with an "error:device:ram://?start=0&end=0x100" and
recursively look for a Controller willing to return an error about
device:ram -- presumably, the one which returns objects about device:ram.
> 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().)
OTOH, finalize() isn't, AFAIK, gauranteed to be called when an
object is garbage-collected, but the more paranoid factories may well
implement reference-counting in their returned objects. (Device objects,
AFAIK, will never form cycles, so reference-counting should work
well. This needs more thought, though.)
> >Don't get me wrong. This feels to me to be one of the best solutions to
> >device allocation I've seen.
Right on, and for the reasons GCHII gave.
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
