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

[Christian Brauner]

> > 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.

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.

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.

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).

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.

  (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).

  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.