On Tuesday 20 April 2010 11:06:59 Alfeiks wrote: > Hi, > > On Mon, Apr 19, 2010 at 06:32:14PM +0400, Dmitry Gromada wrote: > > I written the documentation concerning the driver model is proposed to be > > used in jari. Main structures are designed, and the server layer is > > implemented as far back as January. The code is already in the master > > repository. Bringing into accord with the model of existing drivers will > > begin just all concerning IDL will be complete. > > yep, I'm working on it ;) > > > I will grateful for all constructional critics concerning the idea and > > the documentation. Also, any opposite propositions can be brought. > > Some basic note: > - something bad with headers (I cannot copypaste from the pdf ;( ) > - it's better to provide examples > - it's good to present some basic structure or smth else concrete
This is _design_ documentation and should not include any examples or detailed structures description. This will be done in programming manual which will be written later. There is IEEE Std 1016-1998 standard which recommends structure and content of design documentation. > > > Best regards, > > Dmitry Gromada > > Well, questions ... > 1. Driver model will manage IPC boxes, and it's queues am I right ? IPC box management is performed in context of the server layer and it's transparent for a developer. > 2. In case of IDL, the protocol layer it's just set of wrappers to > generated code, is it really needed like a separate layer ? I've not quite understood the question. Protocol parser modules should be loosely coupled with IPC and device logic to provide more flexibility. > 3. I don't understand clearly about model itself: > from one side it's a something that makes a deal with client > communication, from other side it might be a distributed one - I mean > that if you have separated drivers (in different address space i.e. > processes) u need to keep IPC/RPC on each side, how it will looks in > this case ? They are programming components, not runtime components. It will one instance per each address space. There is not any problem at all. A device manager registers all needed for IPC/RPC and then do fork per each loaded driver. I can reflect this in the document if it's really needed, but i think it's rather trivial. > 4. Device class protocols: I don't understand clearly how it will works. > On practice, u need to create an interfaces (in terms of IDL) that will > create server and client part (some stubs for your procedures) - and > it's not possible to create there ones runtime. > Well, u will need to manage IDL routines and functions by hand (in case > of predefined interfaces), or parse it manually. Could you describe > more about it ? > IDL routines were exactly part of protocol parsers. Perhaps, also some code will be written by hand. I can't clearly imagine that now. This is individually for each subsystem. Of course, all this will be created at compile time. In runtime only the following information will be provided for the server instance: which types of IPC can be used as transport for each protocol, parser module entry points. > Thanks, > > > _______________________________________________ > > Jarios-dev mailing list > > [email protected] > > http://lists.jarios.org/cgi-bin/mailman/listinfo/jarios-dev > > _______________________________________________ > Jarios-dev mailing list > [email protected] > http://lists.jarios.org/cgi-bin/mailman/listinfo/jarios-dev > Best regards, Dmitry Gromada _______________________________________________ Jarios-dev mailing list [email protected] http://lists.jarios.org/cgi-bin/mailman/listinfo/jarios-dev
