Hi Jonathan,

Thank you for responding to my email. You are right I was a little bit vague 
with the topic, allow me to elaborate:

My starting point for sensors is the sensor 
hat<https://www.raspberrypi.com/products/sense-hat/> for Raspberry Pi. It 
contains humidity, temperature, pressure, IMU, etc. so I am mainly talking 
about embedded sensors which provide their stuff via I2C, SPI or similar 
protocol. A lot of these sensors have kernel drivers thanks to the IIO 
subsystem so the user side is pretty much done.
I think there is room for development on the sensor side, like replacing the 
hardware with software temporarily for testing or other purposes. I can think 
of a simulation which generates for example temperature measurements and those 
are provided to the user (e.g. kernel driver) according to the BME280 sensor's 
register mapping and datasheet. The goal here is that the kernel driver (or 
generally the consumer of sensor output) does not see a difference between real 
hardware and software simulation.
Always fascinated me that a piece of code was written assuming that it will 
access a certain hardware and then I could swap that hardware with a software 
component and see what happens. Is it depending on an undocumented hardware 
behavior? Is it able to handle inconsistent sensor state?

What do you think? Is this something worth looking into?

Regards
Tamás

________________________________
From: Jonathan Cameron <[email protected]>
Sent: Tuesday, June 9, 2026 16:42
To: Tamás Király <[email protected]>
Cc: [email protected] <[email protected]>; [email protected] 
<[email protected]>
Subject: Re: RFC sensor simulation in QEMU

On Tue, 2 Jun 2026 13:23:14 +0000
Tamás Király <[email protected]> wrote:

> Hi all,
>
> I am interested in implementing sensor simulations. I already saw that there 
> are some sensor implementations with varying details in QEMU. My question is 
> the following: Is that a good idea to extend that part of QEMU or new 
> implementations should happen outside of QEMU and some protocol, e.g. vhost 
> user should be used to provide sensors to QEMU? I would like to align with 
> the long term ideas. What was the original intent with the sensor subsystem?

Hi Tamás

'Sensors' is a very broad term. Could you be a little more specific in what
types of sensors you are interested in?

Thanks,

Jonathan

>
> regards
> Tamás Király

Reply via email to