On Fri, Jul 19, 2024 at 09:50:04AM GMT, Ashutosh Dixit wrote:
On Mon, 17 Jun 2024 18:45:57 -0700, Ashutosh Dixit wrote:
Folks,
The below is just an example from one of the earlier OA patches (already
merged):
[PATCH 05/17] drm/xe/oa/uapi: Add/remove OA config perf ops
+static ssize_t show_dynamic_id(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ struct xe_oa_config *oa_config =
+ container_of(attr, typeof(*oa_config), sysfs_metric_id);
+
+ return sysfs_emit(buf, "%d\n", oa_config->id);
+}
+
+static int create_dynamic_oa_sysfs_entry(struct xe_oa *oa,
+ struct xe_oa_config *oa_config)
+{
+ sysfs_attr_init(&oa_config->sysfs_metric_id.attr);
+ oa_config->sysfs_metric_id.attr.name = "id";
+ oa_config->sysfs_metric_id.attr.mode = 0444;
+ oa_config->sysfs_metric_id.show = show_dynamic_id;
+ oa_config->sysfs_metric_id.store = NULL;
+
+ oa_config->attrs[0] = &oa_config->sysfs_metric_id.attr;
+ oa_config->attrs[1] = NULL;
+
+ oa_config->sysfs_metric.name = oa_config->uuid;
+ oa_config->sysfs_metric.attrs = oa_config->attrs;
+
+ return sysfs_create_group(oa->metrics_kobj, &oa_config->sysfs_metric);
+}
So we often expose things in sysfs. The question is: are there general
guidelines for what to do for environments (such as containers) where
userspace cannot access sysfs? E.g. in such cases, do we expose the
information exposed in sysfs via queries (i.e. an ioctl)? Or another way?
What have we done in the past in drm and what should we do in these cases
for Xe?
userspace should be written in a way to handle sysfs potentially not
being around and not crash in that case. Providing limited functionality
is fine and user can decide what to do in that case. Creating
duplicate and alternative API to handle this is not a good solution IMO.
For containers, it's common to mount sysfs read-only to give container
visibility on the host configuration... or parts of it in case you are
giving the container privilege over that part of the system.
Related, on another project I maintain (kmod) including systemd folks:
https://github.com/kmod-project/kmod/issues/10
From https://systemd.io/CONTAINER_INTERFACE/:
Make sure to pre-mount /proc/, /sys/, and /sys/fs/selinux/ before
invoking systemd, and mount /sys/, /sys/fs/selinux/ and /proc/sys/
read-only (the latter via e.g. a read-only bind mount on itself)
that page has more information on other parts of sysfs that people make
writable/readable for similar issues in other subsystems and is worth
reading.
Lucas De Marchi
