Hi, On Tue, Apr 20, 2010 at 02:37:50PM +0400, Dmitry Gromada wrote: > 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. ok > > > > > > 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. I've got it. > > > 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. I think that we will postpone this question due to the IDL discussion. > > > 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. I think that it's good to make a note about it, but if it will be described in the programming manual it doesn't require. > > > 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. ok, it's a implementation related question, not design one.
What about the design - well, I don't have a questions now, but some implementation things continue be unclear for me, I will return to it later. Thanks, > > > 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
