Re: When sysfs is not available (say containers)

["Dixit, Ashutosh" <ashutosh.dixit@intel.com>]

On Fri, 19 Jul 2024 10:26:20 -0700, Lucas De Marchi wrote:
>
> 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.

Thanks for the pointers Lucas, this helps :)

Ashutosh