Hello everybody; I has been fed up with restarting my computer after every compilation so, I have decided to try running the Heeselicht scenarion on qemu (not very wise but just to speed the development process). But I got some errors concerning acpi table parsing, resulting in the intel framebuffer not well detected. So because I am very poor in qemu mastering, may someone tell me whether it would take a lot of work to port the heeselicht scenario on qemu? Or join me on doing this? Any help is welcome (Here is the log file for those who are interested)
Hello Parfait,
On 07/26/2016 01:07 PM, Parfait Tokponnon wrote:
Hello everybody; I has been fed up with restarting my computer after every compilation so, I have decided to try running the Heeselicht scenarion on qemu (not very wise but just to speed the development process). But I got some errors concerning acpi table parsing, resulting in the intel framebuffer not well detected. So because I am very poor in qemu mastering, may someone tell me whether it would take a lot of work to port the heeselicht scenario on qemu? Or join me on doing this? Any help is welcome (Here is the log file for those who are interested)
I can understand that rebooting after every change is frustrating, but at least if you do not touch components that are started during the first boot stage, it is enough to copy them to the USB stick (e.g. from the guest OS via shared folders). Everything that is started dynamically by the cli_monitor is read on demand from the USB sticks filesystem.
Anyway, trying to run the Heeselicht scenario within QEMU in my eye indeed is not recommendable. All the driver configuration is different (no WIFI, other graphics card), using hardware-assisted virtualization within QEMU is *slow* and not actively used by us - with other words not tested. In the end you have to change different drivers within your configuration, with the result of a different setup. So you won't test whast is not working on your hardware, but what is not working in tour QEMU setup ;-).
Best regards Stefan
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Stefan,
Le 27 juil. 2016 08:10, "Stefan Kalkowski" <stefan.kalkowski@...1...> a écrit :
Hello Parfait,
On 07/26/2016 01:07 PM, Parfait Tokponnon wrote:
Hello everybody; I has been fed up with restarting my computer after every compilation so, I have decided to try running the Heeselicht scenarion on qemu (not very wise but just to speed the development process). But I got some errors concerning acpi table parsing, resulting in the intel framebuffer not well detected. So because I am very poor in qemu mastering, may someone tell me whether it would take a lot of work to port the heeselicht scenario on qemu? Or join me on doing this? Any help is welcome (Here is the log file for those who are interested)
I can understand that rebooting after every change is frustrating, but at least if you do not touch components that are started during the first boot stage, it is enough to copy them to the USB stick (e.g. from the guest OS via shared folders). Everything that is started dynamically by the cli_monitor is read on demand from the USB sticks filesystem.
What I am doing reside essentially in the kernel. Basically, I am trying
to introduce support for user-space thread redundancy (to achieve fault tolerance against transient error) in the kernel and analyzing the latency induced in the whole system as complete OS. So i really need to restart the machine.
Anyway, trying to run the Heeselicht scenario within QEMU in my eye indeed is not recommendable. All the driver configuration is different (no WIFI, other graphics card), using hardware-assisted virtualization within QEMU is *slow* and not actively used by us - with other words not tested. In the end you have to change different drivers within your configuration, with the result of a different setup. So you won't test whast is not working on your hardware, but what is not working in tour QEMU setup ;-).
Good to know it. Ok, thanks
Best regards Stefan
What NetFlow Analyzer can do for you? Monitors network bandwidth and
traffic
patterns at an interface-level. Reveals which users, apps, and protocols
are
consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity
planning
reports.http://sdm.link/zohodev2dev
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs
https://github.com/skalk · http://genode.org/
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
Parfait Tokponnon -
Stefan Kalkowski