Re: [PATCH v4 00/31] Introduce SCMI Telemetry FS support

[Cristian Marussi <cristian.marussi@arm.com>]

On Mon, Jun 29, 2026 at 10:22:46AM +0200, Christian Brauner wrote:
> > > Thanks a lot, David !
> > 
> > Let's hope for some guidance regarding the FS side soon.
> > 
> > But yeah, avoiding the in-kernel FS sounds completely reasonable at this point.
> 
> Afaiu, David wanted me to add a few comments on the viability of a
> character device for this.

Hi Christian,

thanks for Your feedback on this.

> 
> I think you usually have at least the following options:
> 
> (1) character device
> (2) notification pipe
> (3) netlink
> (4) well-known AF_UNIX socket
> 
> You then need to consider your constraints. David added a few:
> 
> (i) root can set properties (enable/disable events)
> (ii) non-root can only retrieve properties/events
> 
> I assume you mean real root, i.e., root on the host system or more
> specifically anyone with CAP_SYS_ADMIN or some other relevant
> capability.

Yes.

> 
> This is a rather simple model and gets a lot of head-scratching out of
> the way.
> 
> But root could also mean "root in a users namespace" which makes this
> more complicated as it effectively means that an unprivileged container
> would be enable/disable events. This makes sense if there's a subset of
> events that naturally lends itself to be charged to a container and that
> the container might have a genuine use for.

I had already ruled out any container support with the defunct FS
interface idea, since it does NOT really make any sense with SCMI
telemetry.

> 
> This touches on another design question which decides how complicated
> the whole implementation is going to be: What consumer-producer
> relationship does this need?
> 
> The process subscribing to the telemetry stream might have exclusive
> access. IOW, once you have subscribed to the telemetry stream the
> connect is busy and no new subscribers are allowed. This is a very
> simple model ofc which has advantages.
> 
> On the other end you have the uevent model. Uevents are broadcast to all
> subscribers who have a uevent netlink socket open (glossing over some
> namespacing details that are irrelevant here).

Stream mode is only one of the possible collection mode in SCMI, and
I am not implementing that immediately out of the box, since by the spec
the asynchronous SCMI notification support needed by a reasonably
performant streaming mode implementation is...optional.

At first I will only implement 'polled' mechanims, i.e. in which the
platform updates the Telemetry data as required by the configuration
chosen and the users go and read the data at the known locations when
they see fit.

> 
> You need to figure out what you really need here. The choice of
> transport also has quality of life implications. 
> 
>   (1):
>   A character device is somewhat simple but it means it's all inherently
>   tied to devtmpfs and namespacing it retroactively is not possible. If
>   you ever want to namespace it, i.e., delegate it to unprivileged
>   sandboxes, userspace needs to bind-mount the character device into the
>   container at container startup or have a mechanism to inject said
>   character devices later via the new mount api. It's all possible I'm
>   just pointing out that you're tied to a rather rigid kernel object. But
>   I think in general it is ok.

No containerization support. I am going for a chardev+IOCTLs approach with
the possibility of an alternative RAW direct mmap access to the Telemetry
shared areas from userspace.

> 
>   (2):
>   A while ago David Howells extended pipes with the concept of a
>   watchqueue. A watchqueue is just a pipe with some special properties. It
>   can be created by passing O_NOTIFICATION to pipe(2) "meticulously
>   undocumented" as Jon would say...) into which the kernel splices small,
>   fixed-format notification records:
> 
>   int fds[2];
>   pipe2(fds, O_NOTIFICATION_PIPE);
>   ioctl(fds[0], IOC_WATCH_QUEUE_SET_SIZE, nr_notes);   /* preallocate, 1..512 */
>   ioctl(fds[0], IOC_WATCH_QUEUE_SET_FILTER, &filter);  /* optional */
>   keyctl(KEYCTL_WATCH_KEY, KEY_SPEC_SESSION_KEYRING, fds[0], 0x01); /* subscribe a source */
> 
>   If the ring is full or no free note exists, the record is dropped and
>   PIPE_BUF_FLAG_LOSS is set on the last buffer. So consumers always learn
>   that they missed something — but not what.
> 
>   IOC_WATCH_QUEUE_SET_FILTER takes struct watch_notification_filter with
>   up to 16 watch_notification_type_filter entries. With a filter installed
>   the default is reject and only the type bit + subtype bit + info match
>   let a record through. Passing NULL removes all filters (everything
>   passes).
> 

These are good to know possibilities that I will explore better..thanks !

>   Kinda like a ringbuffer might be something to consider.
>   O_NOTIFICATION_PIPE works from all contexts (hence the preallocation).
> 
>   (3):
>   No.
> 
>   (4):
>   A while ago I added the "coredump socket" to the kernel. Basically,
>   userspace listens on a well-known AF_UNIX socket address (in this case
>   configured via /proc/sys/kernel/core_pattern). The kernel connects to it
>   and sends the coredump data via this socket (with some protocol
>   negotiation at the beginning).
> 
> If you really want to transform the data stream you're receiving into a
> FUSE filesystem I think any of the referenced methods is compatible with
> that. You just refresh the various files when new events come in and
> otherwise show the data that you already have.
> 
> In other words, if you allow multiple consumers the following scenario
> may happen: Consumer A consumes event E_1 and consumer B consumes E_2,
> consumer A now gets E_3. If consumer A is what funnels the data into a
> filesystem then consumer A misses data. That might be fine or might not
> be.
> 

No we already dropped the FUSE extensions idea...the performance hit would
be too much and it just make more sense for the existing libs to
interface with the new IOCTLs interface.

Thanks again !
Cristian