> Usually, reports have the form of XML with the report name as top-level > node type. So in this common case, the report consumer may check for > this condition, e.g., to see if a pointer report as issued by nitpicker > is valid, one may do: > > if (_config.xml().type() == "pointer") ... > > If nitpicker closes the report session, report_rom will clear the > dataspace. So the dataspace will start with a 0 instead of the top-level > XML node. In this case, the 'Attached_rom_dataspace` returns the > '<empty/>' node. In the hypothetical case that a valid report is called > "empty", one could still check whether the dataspace contains a > null-termination at the beginning: > > if (_config.local_addr<char const>()[0]) ... > > In short, it is already possible to distingish both cases, isn't it?
Thanks for the clarification, Norman. I wasn't aware that the 'Attached_rom_dataspace' automagically returns the '<empty/>' node. Works for me ;-) > > Or to put it another way: Initially, i.e. if no > > report session was created (yet), the report_rom delivers an invalid > > dataspace to the ROM clients. Shouldn't the report_rom restore this > > state after the report session was closed? > > You raise a good point. But instead of confronting the ROM client with > an invalid dataspace (which most ROM clients do not anticipate and > therefore don't handle), I would rather deliver a zeroed dataspace > initially to achieve the desired consistency. Thanks for pointing out > this current deficiency! Perfect. ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
