Hi Johannes, > Sure. The scenario consists of two report_rom components. Let's call > these config_rom and report_rom. The report_rom gets its config from > the config_rom so that it can be changed dynamically by a management > component that reports this config to the config_rom. > On session request, the report_rom implementation calls an update() > on its ROM session to the config_rom before looking for a matching > policy. The problem was triggered by the fact that the management > component (unintentionally) released the report session after some > time. Hence, the update() in the report_rom refreshed the dataspace > of the ROM session to the zeroed-out/empty version.
thanks for the explanation. > I don't have a problem with this behaviour in this particular > scenario as the report session must be kept alive for the lifetime of > the management component anyway. However, it raised the question (to > me) whether the config_rom should deliver an invalid dataspace > instead of a valid but empty dataspace. I think, depending on the > report/application, an empty dataspace can for sure be considered > valid. > Nevertheless, I have the feeling, that there should be a > difference whether an empty report has intentionally been reported or > whether the report_rom emptied the dataspace after the report session > has been closed. 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? > 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! Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth ------------------------------------------------------------------------------ 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
