Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	 Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org,
	Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>,
	 Jose Souza <jose.souza@intel.com>
Subject: When sysfs is not available (say containers)
Date: Fri, 19 Jul 2024 09:50:04 -0700	[thread overview]
Message-ID: <871q3p5nsz.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20240618014609.3233427-6-ashutosh.dixit@intel.com>

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?

Thanks.
--
Ashutosh

  reply	other threads:[~2024-07-19 16:54 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18  1:45 [PATCH v19 00/17] Add OA functionality to Xe Ashutosh Dixit
2024-06-18  1:45 ` [PATCH 01/17] drm/xe/perf/uapi: "Perf" layer to support multiple perf counter stream types Ashutosh Dixit
2024-06-18  1:45 ` [PATCH 02/17] drm/xe/perf/uapi: Add perf_stream_paranoid sysctl Ashutosh Dixit
2024-06-18  1:45 ` [PATCH 03/17] drm/xe/oa/uapi: Add OA data formats Ashutosh Dixit
2024-06-18  1:45 ` [PATCH 04/17] drm/xe/oa/uapi: Initialize OA units Ashutosh Dixit
2024-06-18  1:45 ` [PATCH 05/17] drm/xe/oa/uapi: Add/remove OA config perf ops Ashutosh Dixit
2024-07-19 16:50   ` Dixit, Ashutosh [this message]
2024-07-19 17:26     ` When sysfs is not available (say containers) Lucas De Marchi
2024-07-19 23:55       ` Dixit, Ashutosh
2024-06-18  1:45 ` [PATCH 06/17] drm/xe/oa/uapi: Define and parse OA stream properties Ashutosh Dixit
2024-06-18  1:45 ` [PATCH 07/17] drm/xe/oa: OA stream initialization (OAG) Ashutosh Dixit
2024-06-18  1:46 ` [PATCH 08/17] drm/xe/oa/uapi: Expose OA stream fd Ashutosh Dixit
2024-06-18  1:46 ` [PATCH 09/17] drm/xe/oa/uapi: Read file_operation Ashutosh Dixit
2024-06-18  1:46 ` [PATCH 10/17] drm/xe/oa: Add OAR support Ashutosh Dixit
2024-06-18  1:46 ` [PATCH 11/17] drm/xe/oa: Add OAC support Ashutosh Dixit
2024-06-18  1:46 ` [PATCH 12/17] drm/xe/oa/uapi: Query OA unit properties Ashutosh Dixit
2024-06-18  1:46 ` [PATCH 13/17] drm/xe/oa/uapi: OA buffer mmap Ashutosh Dixit
2024-06-18  1:46 ` [PATCH 14/17] drm/xe/oa: Add MMIO trigger support Ashutosh Dixit
2024-06-18  1:46 ` [PATCH 15/17] drm/xe/oa: Override GuC RC with OA on PVC Ashutosh Dixit
2024-06-18  1:46 ` [PATCH 16/17] drm/xe/oa: Changes to OA_TAKEN Ashutosh Dixit
2024-06-18  1:46 ` [PATCH 17/17] drm/xe/oa: Enable Xe2+ overrun mode Ashutosh Dixit
2024-06-18  1:51 ` ✓ CI.Patch_applied: success for Add OA functionality to Xe (rev19) Patchwork
2024-06-18  1:52 ` ✗ CI.checkpatch: warning " Patchwork
2024-06-18  1:53 ` ✓ CI.KUnit: success " Patchwork
2024-06-18  2:04 ` ✓ CI.Build: " Patchwork
2024-06-18  2:06 ` ✗ CI.Hooks: failure " Patchwork
2024-06-18  2:08 ` ✓ CI.checksparse: success " Patchwork
2024-06-18  2:30 ` ✓ CI.BAT: " Patchwork
2024-06-18 17:49 ` ✗ CI.FULL: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871q3p5nsz.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=jose.souza@intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=umesh.nerlige.ramappa@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox