The old sensor driver doesn't have an unified upperhalf at all:
vfs -> sensor upper half -> sensor lower half
\----> (device-specific) chardev
Even with the same type sensor(e.g. accelerometer),
the driver for ST uses different ioctl/struct from Freescale(even the same
vendor but different series),
which is a nightmare for userspace sensor application.
So from the design point of view, the old approach is no difference from
accessing the hardware register directly.
On Thu, Dec 4, 2025 at 2:19 PM <[email protected]> wrote:
> Maybe the previous post meant that the drivers should/could provide both
> interfaces, ie. both the old and the new one?
>
> As in:
>
> Hardware lower-half -> uORB upper half -> chardev
> \----> (device-specific) chardev
>
> I think I already saw similar suggestion somewhere and for example
> BMP180 driver is implemented that way.
>
> On 2025-12-04 03:59, Matteo Golin wrote:
> > I believe that is the current implementation:
> >
> > Hardware lower-half -> uORB upper half -> chardev
> >
> > On Wed, Dec 3, 2025, 8:21 PM spudaneco <[email protected]> wrote:
> >
> >> What is needed is to be able to share common logic between character
> >> and
> >> uORB drivers. In NuttX this is normally done with an upper half/lower
> >> half
> >> driver architecture. In this case the common, low level, hardware
> >> specific
> >> lower half would be shared by a character driver and a uORB upper
> >> half.
> >>
>