Hello Martin, > a few comments on your current code (please don't take it as criticism, > but rather as TODOs :)):
No problem, because it is a prototype. > * I agree with the comments by Jiri Svoboda. Try to split the IPC code > from compctl into a module in libc, to make compctl more abstract and > the IPC stubs reusable. OK. I was planning to do so even without your comments. > * Currently you have disabled kfb. Only temporarily. >> a) kfb is used on non-ia32, non-amd64 platforms. > b) kfb should be still usable in case vesafb fails to initialize (for > any reason). > > There needs to be some kind of hand-off between kfb and vesafb, both > drivers need to coexist side-by-side in a limited way. To be honest, I don't have any idea how to do it in an elegant way. May be we should disable autoloading and load drivers explicitly by compositor? Is there a mechanism to load drivers on demand? > * I know that this is not your idea, but the dual naming of the > compositor nodes (comp:0/* vs. comp/:0) is somewhat confusing. I > would really prefer creating the control node as for example > comp:0/ctrl. At first I planned to add a a /ctl node to comp:0/ directory, but then decided that it will be rather natural to control compositor through it main node. But if you want the former way, I'll do. > * The solution with the separate thread in vesafb is not very elegant. > You should first initialize the hardware (port_init()) and only after > the initialization succeeds register the DDF function. Well, then what to do with compositor which starts before driver? > * CamelCase in libvbe It was done on purpose: to name structures like in VBE standard. Could naming convention be weaken here? _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
