All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] sparc64: Expose mdesc to sysfs
@ 2017-09-16  5:08 Eric Saint Etienne
  2017-09-16  6:08 ` David Miller
                   ` (76 more replies)
  0 siblings, 77 replies; 78+ messages in thread
From: Eric Saint Etienne @ 2017-09-16  5:08 UTC (permalink / raw)
  To: sparclinux

To get a snapshot as complete as possible of what the system is composed of,
this commit adds the ability to browse machine description from sysfs.

This commit eases porting of user-space utilities that exist on other architectures
like lshw for instance.

Whenever the HV changes machine description content, sysfs will be re-populated.
This is done almost atomically by swapping the old mdesc sysfs folder with the
new one. While the tree under the new folder is being created, reading from
/sys/firmware/mdesc will return EAGAIN. That way userspace programs will not see
stale content in /sys/firmware/mdesc

Signed-off-by: Eric Saint Etienne <eric.saint.etienne@oracle.com>
Reviewed-by: Dave Aldridge <david.j.aldridge@oracle.com> 
---
 arch/sparc/Kconfig              |    8 +
 arch/sparc/kernel/Makefile      |    2 +
 arch/sparc/kernel/mdesc.c       |    7 +
 arch/sparc/kernel/mdesc_sysfs.c |  830 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 847 insertions(+), 0 deletions(-)
 create mode 100644 arch/sparc/kernel/mdesc_sysfs.c

diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index cac67aa..5ecdebf 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -508,6 +508,14 @@ config UBOOT_ENTRY_ADDR
 endmenu
 endif
 
+config MDESC_SYSFS
+	bool "Maps machine description to sysfs"
+	depends on SPARC64
+	default y
+	---help---
+	  If you say Y here, the directed acyclic graph described in the machine
+	  description will be expanded and made available in /sys/firmware/mdesc
+
 endmenu
 
 menu "Bus options (PCI etc.)"
diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile
index 5e6463d..213179e 100644
--- a/arch/sparc/kernel/Makefile
+++ b/arch/sparc/kernel/Makefile
@@ -122,6 +122,8 @@ obj-$(CONFIG_SPARC64)	+= $(pc--y)
 
 obj-$(CONFIG_UPROBES)	+= uprobes.o
 
+obj-$(CONFIG_MDESC_SYSFS) += mdesc_sysfs.o
+
 obj-$(CONFIG_SPARC64)	+= jump_label.o
 
 obj-$(CONFIG_SPARC64)	+= kexec_shim.o
diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel/mdesc.c
index 1fbf6ff..2e999fe 100644
--- a/arch/sparc/kernel/mdesc.c
+++ b/arch/sparc/kernel/mdesc.c
@@ -92,6 +92,10 @@ struct md_node_ops {
 	mdesc_node_match_f node_match;
 };
 
+#ifdef MDESC_SYSFS
+int mdesc_sysfs_populate(void);
+#endif
+
 static int get_vdev_port_node_info(struct mdesc_handle *md, u64 node,
 	union md_node_info *node_info);
 static bool vdev_port_node_match(union md_node_info *a_node_info,
@@ -506,6 +510,9 @@ void mdesc_update(void)
 		cur_mdesc = hp;
 		spin_unlock_irqrestore(&mdesc_lock, flags);
 
+#ifdef MDESC_SYSFS
+		mdesc_sysfs_populate();
+#endif
 		mdesc_notify_clients(orig_hp, hp);
 
 		spin_lock_irqsave(&mdesc_lock, flags);
diff --git a/arch/sparc/kernel/mdesc_sysfs.c b/arch/sparc/kernel/mdesc_sysfs.c
new file mode 100644
index 0000000..6fb8713
--- /dev/null
+++ b/arch/sparc/kernel/mdesc_sysfs.c
@@ -0,0 +1,830 @@
+/*
+ * mdesc_sysfs.c - Maps machine description DAG to sysfs
+ *
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING.  If not, write to
+ * the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139,
+ * USA.
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <asm/mdesc.h>
+
+#define MDESC_SYSFS_TOO_LARGE "Error: Not enough space to output the data, retrieve it from /dev/mdesc instead."
+
+/*
+ * Machine Description is described in slides 37-39 here:
+ * http://www.oracle.com/technetwork/systems/opensparc/2008-oct-opensparc-slide-cast-09-mw-1539018.html
+ *
+ * It is composed of three main sections decribed by the following mdesc header.
+ * Since these blocks are contiguous, describing their size is sufficient to
+ * precisely locate them within the mdesc blob.
+ *
+ * - The NODE block contains the nodes of the directed acyclic graph (DAG)
+ * - The NAME block contains names of properties referred to by the DAG nodes
+ * - The DATA block contains values for the properties: strings and binary data
+ *
+ * A public specification of mdesc is available online at:
+ * https://kenai.com/downloads/hypervisor/hypervisor-api-3.0draft7.pdf
+ */
+struct mdesc_hdr {
+	u32	version; /* Transport version */
+	u32	node_sz; /* node block size */
+	u32	name_sz; /* name block size */
+	u32	data_sz; /* data block size */
+} __aligned(16)__;
+
+struct mdesc_elem {
+	u8	tag;
+#define MD_LIST_END	0x00
+#define MD_NODE		0x4e
+#define MD_NODE_END	0x45
+#define MD_NOOP		0x20
+#define MD_PROP_ARC	0x61
+#define MD_PROP_VAL	0x76
+#define MD_PROP_STR	0x73
+#define MD_PROP_DATA	0x64
+	u8	name_len;
+	u16	resv;
+	u32	name_offset;
+	union {
+		struct {
+			u32	data_len;
+			u32	data_offset;
+		} data;
+		u64	val;
+	} d;
+};
+
+struct mdesc_mem_ops {
+	struct mdesc_handle *(*alloc)(unsigned int mdesc_size);
+	void (*free)(struct mdesc_handle *handle);
+};
+
+struct mdesc_handle {
+	struct list_head     list;
+	struct mdesc_mem_ops *mops;
+	void                 *self_base;
+	atomic_t             refcnt;
+	unsigned int         handle_size;
+	struct mdesc_hdr     mdesc;
+};
+
+/*
+ * The following 3 functions return a pointer of the right type to the
+ * 3 main mdesc blocks
+ */
+
+static inline struct mdesc_elem *node_block(struct mdesc_hdr *mdesc)
+{
+	return (struct mdesc_elem *) (mdesc + 1);
+}
+
+static inline void *name_block(struct mdesc_hdr *mdesc)
+{
+	return ((void *) node_block(mdesc)) + mdesc->node_sz;
+}
+
+static inline void *data_block(struct mdesc_hdr *mdesc)
+{
+	return ((void *) name_block(mdesc)) + mdesc->name_sz;
+}
+
+/*
+ * Dynamically allocates the right amount of characters to format according
+ * to the printf-like format specified in "fmt".
+ * "*buf" is allocated and filled.
+ *
+ * Return 0 upon success
+ */
+static int alloc_sprintf(char **buf, const char *fmt, ...)
+{
+	va_list args;
+	size_t len, actual;
+
+	va_start(args, fmt);
+	len = vsnprintf(NULL, 0, fmt, args);
+	va_end(args);
+
+	*buf = kmalloc(len+1, GFP_KERNEL);
+	if (!*buf)
+		return -ENOMEM;
+
+	va_start(args, fmt);
+	actual = vscnprintf(*buf, len + 1, fmt, args);
+	va_end(args);
+
+	if (actual != len) {
+		kfree(*buf);
+		*buf = NULL;
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+/*
+ * Flags used with the following formatting functions that modify the way
+ * node names are formatted
+ */
+#define FORMAT_APPEND    0x01
+#define FORMAT_USE_INDEX 0x02
+
+/*
+ * Take an arc node in "ep" and format it using the "id" field as to avoid
+ * collision when adding to sysfs.
+ * Ex: multiple "cpu" nodes in the same folder will be named: "0", "1"...
+ *
+ * When FORMAT_APPEND is used, the names will become: "cpu0", "cpu1"...
+ * The formatted string is found in *formatted, to be freed by the caller
+ *
+ * Return 0 upon success
+ */
+static int format_using_id(struct mdesc_handle *hp,
+			   struct mdesc_elem *ep,
+			   char const *name,
+			   char **formatted,
+			   unsigned int flags,
+			   unsigned int index,
+			   unsigned int total)
+{
+	const u64 *prop_id = mdesc_get_property(hp, ep->d.val, "id", NULL);
+
+	if (!prop_id) {
+		pr_err("mdesc %s doesn't have a property \"id\"\n", name);
+		return -ENOENT;
+	}
+
+	if (flags & FORMAT_APPEND)
+		return alloc_sprintf(formatted, "%s%lld", name, *prop_id);
+
+	return alloc_sprintf(formatted, "%lld", *prop_id);
+}
+
+/*
+ * Take an arc node in "ep" and format it using the "name" field as to avoid
+ * collision when adding to sysfs.
+ * Ex: multiple "virtual-device" nodes in the same folder will be named:
+ * "disk", "network"...
+ *
+ * When FORMAT_APPEND is used: "virtual-device-disk", virtual-device-network"...
+ *
+ * Because the "name" field is not guaranteed to be unique, one can use the
+ * flag FORMAT_USE_INDEX: "virtual-device0-disk", virtual-device1-network"...
+ * In this case "index" is used.
+ *
+ * The formatted string is found in *formatted, to be freed by the caller
+ *
+ * Return 0 upon success
+ */
+static int format_using_name(struct mdesc_handle *hp,
+			     struct mdesc_elem *ep,
+			     const char *name,
+			     char **formatted,
+			     unsigned int flags,
+			     unsigned int index,
+			     unsigned int total)
+{
+	const char *prop_name = mdesc_get_property(hp, ep->d.val, "name", NULL);
+
+	if (!prop_name) {
+		pr_err("mdesc %s doesn't have a property \"name\"\n", name);
+		return -ENOENT;
+	}
+
+	if (flags & FORMAT_APPEND) {
+		if (flags & FORMAT_USE_INDEX)
+			return alloc_sprintf(formatted, "%s%d_%s",
+					     name, index, prop_name);
+		else
+			return alloc_sprintf(formatted, "%s_%s",
+					     name, prop_name);
+	}
+
+	if (flags & FORMAT_USE_INDEX)
+		return alloc_sprintf(formatted, "%s%d", prop_name, index);
+	else
+		return alloc_sprintf(formatted, "%s", prop_name);
+}
+
+/*
+ * Default formatting used in format_name() for arcs nodes.
+ * Called when we find multiple arcs with the same name for which no
+ * formatting is specified in format_nodes array.
+ * This default formatting guarantees uniqueness because it is using the node
+ * index in the mdesc nodes array
+ */
+static char *format_name_fallback(struct mdesc_handle *hp,
+				  struct mdesc_elem *ep,
+				  const char *name,
+				  unsigned int    index,
+				  unsigned int    total)
+{
+	char *formatted = NULL;
+	int err;
+
+	err = alloc_sprintf(&formatted, "%s_0x%x", name, ep->d.val);
+	return err ? NULL : formatted;
+}
+
+struct format_node {
+	char	*name;
+	int	(*format)(struct mdesc_handle*, struct mdesc_elem*, const char*,
+			char**, unsigned int, unsigned int, unsigned int);
+	unsigned int flags;
+};
+
+struct format_node format_nodes[] = {
+#define FORMAT_APPEND_USE_INDEX (FORMAT_APPEND | FORMAT_USE_INDEX)
+	{ "virtual-device",       format_using_name, FORMAT_APPEND_USE_INDEX },
+	{ "domain-services-port", format_using_id,   FORMAT_APPEND },
+	{ "virtual-device-port",  format_using_id,   FORMAT_APPEND },
+	{ "channel-endpoint",     format_using_id,   FORMAT_APPEND },
+	{ "cpu",                  format_using_id,   FORMAT_APPEND },
+	{ NULL, NULL, 0 }
+};
+
+/*
+ * Format the name of an arc node according to the table "format_nodes".
+ * If no entry is found for the arc node in "ep", it falls back to using
+ * format_name_fallback()
+ * Returns the formatted string, to be freed by the caller
+ */
+static char *format_name(struct mdesc_handle *hp,
+			 struct mdesc_elem *ep,
+			 const char *name,
+			 int    index,
+			 int    total)
+{
+	struct format_node *fn;
+	char   *formatted = NULL;
+	bool   found = false;
+	int    err = 0;
+
+	for (fn = format_nodes; fn->name; fn++) {
+		if (strcmp(fn->name, name))
+			continue;
+		err = fn->format(hp, ep, name, &formatted,
+				 fn->flags, index, total);
+		found = true;
+		break;
+	}
+
+	if (!found && (total != 1)) {
+		/*
+		 * there's no handler for this node and we've got more
+		 * than one so we format it by appending the index
+		 * (by order of appearance)
+		 */
+		err = alloc_sprintf(&formatted, "%s%lld", name, index);
+	}
+
+	if (err)
+		return format_name_fallback(hp, ep, name, index, total);
+
+	return formatted;
+}
+
+/*
+ * Takes an arc node in "ep" and create a folder in sysfs with the name as
+ * provided by format_name() which uses the format_nodes array as input
+ * "total" is the number of arcs nodes with the same type (ex: cpu)
+ * "index" is the occurrence number of the arc node (ex: cpu number 32)
+ * Fills *kobj with the kobject
+ * Return 0 upon success
+ */
+static int create_sysfs_folder(struct mdesc_handle *hp,
+			       struct mdesc_elem *ep,
+			       const char *name,
+			       struct kobject **kobj,
+			       struct kobject *parent_kobj,
+			       unsigned int index,
+			       unsigned int total)
+{
+	char *formatted;
+	int  err = 0;
+
+	formatted = format_name(hp, ep, name, index, total);
+	if (!formatted)
+		formatted = (char *) name;
+
+	*kobj = kobject_create_and_add(formatted, parent_kobj);
+
+	err = (*kobj = NULL) ? -ENOMEM : 0;
+	if (err)
+		pr_err("mdesc_sysfs: unable to create sysfs entry for \"%s\"\n",
+		       name);
+
+	if (formatted != name)
+		kfree(formatted);
+
+	return err;
+}
+
+/*
+ * Similar to create_sysfs_folder() except that because the node in "ep"
+ * already exist elsewhere in sysfs, a link is created instead.
+ * Return 0 upon success
+ */
+static int create_sysfs_link(struct mdesc_handle *hp,
+			     struct mdesc_elem *ep,
+			     const char *name,
+			     struct kobject *target_kobj,
+			     struct kobject *parent_kobj,
+			     unsigned int index,
+			     unsigned int total)
+{
+	char *formatted;
+	int  err = 0;
+
+	formatted = format_name(hp, ep, name, index, total);
+	if (!formatted)
+		formatted = (char *) name;
+
+	err = sysfs_create_link(parent_kobj, target_kobj, formatted);
+	if (err)
+		pr_err("mdesc_sysfs: unable to create sysfs link for \"%s\"\n",
+		       name);
+
+	if (formatted != name)
+		kfree(formatted);
+
+	return err;
+}
+
+struct mdesc_arcs {
+	struct list_head list;
+	const char *name;
+	unsigned int count;
+};
+
+/*
+ * Take a node in "ep" and build a linked list of mdesc_arcs elements.
+ * Each element contains a name and how many occurrences exists in "ep".
+ * Return 0 upon success
+ */
+static int sysfs_populate_build_arcs_list(struct mdesc_handle *hp,
+					  struct mdesc_elem *ep,
+					  struct mdesc_arcs *arcs_list)
+{
+	struct mdesc_elem *base = node_block(&hp->mdesc);
+	const char *names = name_block(&hp->mdesc);
+
+	for (ep++; ep->tag != MD_NODE_END; ep++) {
+		const char *arc_name;
+		struct mdesc_arcs *p;
+
+		/* We only care of the forward arcs of the DAG */
+		if (ep->tag != MD_PROP_ARC ||
+				strcmp(names + ep->name_offset, "fwd"))
+			continue;
+
+		arc_name = names + (base + ep->d.val)->name_offset;
+		list_for_each_entry(p, &arcs_list->list, list) {
+			if (!strcmp(p->name, arc_name))
+				break;
+		}
+		/* Have we found arc_name in the list? */
+		if (p = arcs_list) {
+			/* no, we add it to the list */
+			p = kzalloc(sizeof(struct mdesc_arcs), GFP_KERNEL);
+			if (p = NULL) {
+				struct list_head *pos, *q;
+
+				/* An error occured: free the whole list */
+				list_for_each_safe(pos, q, &arcs_list->list) {
+					p = list_entry(pos, struct mdesc_arcs,
+							list);
+					list_del(pos);
+					kfree(p);
+				}
+				return -ENOMEM;
+			}
+			p->name = arc_name;
+			/* add tail allows to keep mdesc's order */
+			list_add_tail(&p->list, &arcs_list->list);
+		}
+		/* increment the occurrence for this arc */
+		p->count++;
+	}
+	return 0;
+}
+
+struct sysfs_property {
+	struct kobj_attribute kattr;
+	char *value;
+	unsigned int length;
+};
+
+static bool updating;
+
+static ssize_t mdesc_sysfs_show(struct kobject *object,
+				struct kobj_attribute *attr,
+				char *buf)
+{
+	struct sysfs_property *prop;
+
+	if (updating)
+		return -EAGAIN; /* This version is stale */
+
+	prop = container_of(attr, struct sysfs_property, kattr);
+	if (prop->length <= PAGE_SIZE) {
+		memcpy(buf, prop->value, prop->length);
+		return prop->length;
+	}
+	return sprintf(buf, "%s\n", MDESC_SYSFS_TOO_LARGE);
+}
+
+/*
+ * Append a property to the list that will be later
+ * passed to sysfs_create_files()
+ * "attributes" is a pointer to an array of "struct attribute*"
+ */
+static int add_property(struct sysfs_property *prop,
+			struct attribute ***attributes,
+			int *length,
+			int *size)
+{
+	if (*size <= (*length + 1)) {
+		struct attribute **p;
+
+		*size += 16; /* pre-allocation to relieve the allocator */
+		p = krealloc(*attributes, *size * sizeof(struct attribute *),
+				GFP_KERNEL);
+		if (!p)
+			return -ENOMEM;
+
+		*attributes = p;
+	}
+	(*attributes)[(*length)++] = &prop->kattr.attr;
+	/* the array must be NULL terminated */
+	(*attributes)[*length] = NULL;
+	return 0;
+}
+
+/*
+ * Given an arc node in "ep", loop through its entries and create
+ * a list of attributes suitable for sysfs_create_files()
+ * the entries should be be unique within "ep" but there are versions
+ * where entries are duplicated, so we only add them once to the list
+ */
+static int mdesc_sysfs_add_propeties(struct mdesc_handle *hp,
+				     struct mdesc_elem *ep,
+				     struct kobject *parent_kobj)
+{
+	const char *names = name_block(&hp->mdesc);
+	void *data = data_block(&hp->mdesc);
+	struct attribute **sysfs_attributes = NULL;
+	int sysfs_attributes_length = 0;
+	int sysfs_attributes_size = 0;
+	int err;
+
+	for (ep++; ep->tag != MD_NODE_END; ep++) {
+		struct sysfs_property *prop;
+		char *s = NULL;
+		size_t len = 0;
+		bool valid = false;
+
+		switch (ep->tag) {
+		case MD_PROP_VAL:
+			err = alloc_sprintf(&s, "%lld\n", ep->d.val);
+			if (err)
+				return -ENOMEM;
+			len = strlen(s);
+			valid = true;
+			break;
+		case MD_PROP_STR:
+			s = kstrndup(data + ep->d.data.data_offset,
+				     ep->d.data.data_len, GFP_KERNEL);
+			s = kmalloc(ep->d.data.data_len+1, GFP_KERNEL);
+			if (s = NULL)
+				return -ENOMEM;
+			memcpy(s, data + ep->d.data.data_offset,
+			       ep->d.data.data_len-1);
+			s[ep->d.data.data_len-1] = '\n';
+			s[ep->d.data.data_len] = '\0';
+			len = ep->d.data.data_len;
+			valid = true;
+			break;
+		case MD_PROP_DATA:
+			s = kmalloc(ep->d.data.data_len, GFP_KERNEL);
+			if (s = NULL)
+				return -ENOMEM;
+			memcpy(s, data + ep->d.data.data_offset,
+					ep->d.data.data_len);
+			len = ep->d.data.data_len;
+			valid = true;
+			break;
+		default:
+			break;
+		}
+
+		prop = kmalloc(sizeof(*prop), GFP_KERNEL);
+		if (!prop) {
+			kfree(s);
+			kfree(sysfs_attributes);
+			return -ENOMEM;
+		}
+
+		if (valid) {
+			const char *c_name = names + ep->name_offset;
+			char *name;
+			int i;
+			bool found = false;
+
+			/*
+			 * Check if a property with the same name
+			 * has already been added
+			 */
+			for (i = 0; i < sysfs_attributes_length; i++) {
+				struct sysfs_property *prop;
+
+				prop = container_of(sysfs_attributes[i],
+						    struct sysfs_property,
+						    kattr.attr);
+				if (!strcmp(prop->kattr.attr.name, c_name)) {
+					found = true;
+					break;
+				}
+			}
+			if (found) {
+				pr_info("mdesc_sysfs: duplicate property found\n");
+				continue;
+			}
+
+			name = kstrdup(c_name, GFP_KERNEL);
+			if (!name) {
+				kfree(s);
+				kfree(sysfs_attributes);
+				return -ENOMEM;
+			}
+
+			/* Set the name */
+			prop->kattr.attr.name = name;
+			prop->kattr.attr.mode = S_IRUSR;
+			prop->kattr.show = mdesc_sysfs_show;
+			prop->kattr.store = NULL;
+			prop->value = s;
+			prop->length = len;
+
+			/* Add to the (automatically growing) array */
+			add_property(prop, &sysfs_attributes,
+				     &sysfs_attributes_length,
+				     &sysfs_attributes_size);
+		}
+	}
+
+	if (sysfs_attributes) {
+		int err;
+		const struct attribute **pattr = (const struct attribute **)
+						 sysfs_attributes;
+
+		err = sysfs_create_files(parent_kobj, pattr);
+		if (err)
+			pr_err("mdesc_sysfs: unable to create sysfs properties\n");
+
+		/*
+		 * Free the array of attributes, but not the individual elements
+		 * because each element points to a "struct sysfs_property" that
+		 * mdesc_sysfs_show() uses whenever users read from sysfs
+		 */
+		kfree(sysfs_attributes);
+	}
+
+	return 0;
+}
+
+/*
+ * Function called on the root that recursively add nodes to sysfs
+ * It first looks at the current node in "ep", gathering statistics
+ * on every forward arcs it points to,
+ * then for every arc type it create a sysfs folder or link
+ * Finally it adds the properties (non arcs) to sysfs
+ * Return 0 upon success
+ */
+static int sysfs_populate(struct mdesc_handle *hp,
+			  struct mdesc_elem *ep,
+			  struct kobject *parent_kobj,
+			  struct kobject **all_nodes)
+{
+	struct mdesc_elem *base = node_block(&hp->mdesc);
+	const char *names = name_block(&hp->mdesc);
+	struct mdesc_arcs arcs_list, *p;
+	struct list_head *pos, *q;
+	int err = 0;
+
+	/*
+	 * Check that it's indeed an arc node
+	 * and lose the 1st entry as it's not useful hereafter
+	 */
+	if (ep++->tag != MD_NODE) {
+		pr_err("mdesc_sysfs: Not a valid arc node\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * In a high level language we'd create a dictionary
+	 * for example: {"cpu": 64", "memory": 1, ...}
+	 * In the kernel we use a linked list of structs.
+	 * We end up with: ("cpu", 64) --> ("memory", 1) -->...
+	 */
+	INIT_LIST_HEAD(&arcs_list.list);
+	err = sysfs_populate_build_arcs_list(hp, ep, &arcs_list);
+	if (err)
+		return err;
+
+	/*
+	 * For each arc type, we browse the current arc "ep" and
+	 * add to sysfs. That allows us to keep an index for these
+	 * arcs that don't contain an "id" or "name" field
+	 */
+	list_for_each_entry(p, &arcs_list.list, list) {
+		struct mdesc_elem *elem;
+		unsigned int index = 0;
+
+		for (elem = ep; elem->tag != MD_NODE_END; elem++) {
+			struct kobject *kobj;
+			const char *name;
+
+			/* Need to be a forward arc... */
+			if (elem->tag != MD_PROP_ARC ||
+			    strcmp(names + elem->name_offset, "fwd"))
+				continue;
+
+			/*
+			 * ...whose name matches the element of the list
+			 * that we're currently considering
+			 */
+			name = names + (base + elem->d.val)->name_offset;
+			if (strcmp(p->name, name))
+				continue;
+
+			/* Have we already added this arc to sysfs? */
+			if (all_nodes[elem->d.val]) {
+				/* Yes, we link to it */
+				err = create_sysfs_link(hp, elem, name,
+					all_nodes[elem->d.val], parent_kobj,
+					index, p->count);
+			} else {
+				/* No, we create a folder for it */
+				err = create_sysfs_folder(hp, elem, name,
+					&kobj, parent_kobj, index, p->count);
+				if (err)
+					return -ENOMEM;
+
+				all_nodes[elem->d.val] = kobj;
+
+				/* And we add to sysfs whatever it contains */
+				sysfs_populate(hp, base + elem->d.val,
+					       kobj, all_nodes);
+			}
+
+			/*
+			 * If it's the last entry of its kind, there's
+			 * no point in looping again
+			 */
+			if (++index = p->count)
+				break;
+		}
+	}
+
+	/* Free the linked list */
+	list_for_each_safe(pos, q, &arcs_list.list) {
+		p = list_entry(pos, struct mdesc_arcs, list);
+		list_del(pos);
+		kfree(p);
+	}
+
+	/* Add the properties (non-arc) to sysfs (string, int, binary data) */
+	return mdesc_sysfs_add_propeties(hp, ep, parent_kobj);
+}
+
+static struct kobject *mdesc_kobj;
+
+int mdesc_sysfs_populate(void)
+{
+	struct mdesc_handle *hp;
+	unsigned int num_node;
+	struct kobject **all_nodes, *old_mdesc_kobj;
+	unsigned int major, minor;
+	mode_t mode;
+	int retval = 0;
+
+	hp = mdesc_grab();
+	if (!hp) {
+		pr_err("mdesc_sysfs: hv mdesc not found\n");
+		return -ENODEV;
+	}
+
+	major = hp->mdesc.version >> 16;
+	minor = hp->mdesc.version & 0xffff;
+
+	if (major != 1) {
+		pr_err("mdesc_sysfs: unsupported hv mdesc version: %d.%d\n",
+		       major, minor);
+		mdesc_release(hp);
+		return -EINVAL;
+	}
+
+	pr_info("mdesc_sysfs: machine desc version %d.%d\n", major, minor);
+
+	num_node = hp->mdesc.node_sz / sizeof(struct mdesc_hdr);
+	all_nodes = kcalloc(num_node, sizeof(struct kobject *), GFP_KERNEL);
+	if (!all_nodes) {
+		mdesc_release(hp);
+		return -ENOMEM;
+	}
+
+	updating = true;
+
+	old_mdesc_kobj = mdesc_kobj;
+	mdesc_kobj = kobject_create_and_add(".mdesc.tmp", firmware_kobj);
+	if (!mdesc_kobj) {
+		pr_err("mdesc_sysfs: unable to create sysfs entry\n");
+		kfree(all_nodes);
+		mdesc_release(hp);
+		return -ENOMEM;
+	}
+	mode = mdesc_kobj->sd->mode;
+ 	/* Remove access to everyone since we're populating
+ 	 * the tree. Regardless, root has always access! */
+	mdesc_kobj->sd->mode &= ~0777;
+
+	retval = sysfs_populate(hp, node_block(&hp->mdesc),
+				mdesc_kobj, all_nodes);
+
+	mdesc_release(hp);
+	kfree(all_nodes);
+
+	/* Rename existing mdesc to avoid conflicts */
+	if (retval)
+		return retval;
+
+	if (old_mdesc_kobj) {
+		retval = kobject_rename(old_mdesc_kobj, ".mdesc.old");
+		if (retval) {
+			pr_err("mdesc_sysfs: unable to rename /sys/firmware/mdesc\n");
+			kobject_del(mdesc_kobj);
+			kobject_put(mdesc_kobj);
+			updating = false;
+			return retval;
+		}
+	}
+
+	/* Restore original mode and set name */
+	retval = kobject_rename(mdesc_kobj, "mdesc");
+	if (!retval) {
+		mdesc_kobj->sd->mode = mode;
+		if (old_mdesc_kobj) {
+			kobject_del(old_mdesc_kobj);
+			kobject_put(old_mdesc_kobj);
+		}
+	} else {
+		int dummy;
+
+		/* Attempt to restore the old entry (if any) */
+		if (old_mdesc_kobj)
+			dummy = kobject_rename(old_mdesc_kobj, "mdesc");
+		kobject_del(mdesc_kobj);
+		kobject_put(mdesc_kobj);
+	}
+
+	updating = false;
+
+	return retval;
+}
+EXPORT_SYMBOL(mdesc_sysfs_populate);
+
+MODULE_DESCRIPTION("Maps machine description graph to sysfs in /sys/firmware/mdesc");
+MODULE_AUTHOR("Oracle");
+MODULE_LICENSE("GPL");
+
+static int __init mdesc_sysfs_init(void)
+{
+	return mdesc_sysfs_populate();
+}
+
+static void __exit mdesc_sysfs_cleanup(void)
+{
+	if (mdesc_kobj) {
+		kobject_del(mdesc_kobj);
+		kobject_put(mdesc_kobj);
+	}
+}
+
+module_init(mdesc_sysfs_init);
+module_exit(mdesc_sysfs_cleanup);
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
@ 2017-09-16  6:08 ` David Miller
  2017-09-18 14:23 ` Eric Saint Etienne
                   ` (75 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-16  6:08 UTC (permalink / raw)
  To: sparclinux

From: Eric Saint Etienne <eric.saint.etienne@oracle.com>
Date: Sat, 16 Sep 2017 05:36:03 +0100

> To get a snapshot as complete as possible of what the system is
> composed of,
> this commit adds the ability to browse machine description from sysfs.
> 
> This commit eases porting of user-space utilities that exist on other
> architectures
> like lshw for instance.
> 
> Whenever the HV changes machine description content, sysfs will be
> autopmatically
> re-populated. This is done almost atomically by swapping the old mdesc
> sysfs folder
> with the new one. While the tree under the new folder is being
> created, reading from
> /sys/firmware/mdesc will return EAGAIN. That way userspace programs
> will not see
> stale content in /sys/firmware/mdesc
> 
> Signed-off-by: Eric Saint Etienne <eric.saint.etienne@oracle.com>
> Reviewed-by: Dave Aldridge <david.j.aldridge@oracle.com>

Please explain why /dev/mdesc could not be extended to do what you
need, such as sending an event to userspace.

There is absolutely no reason to present a formatted version of
mdesc under sysfs.

That is entirely a userspace problem, where the userspace component
grabs the mdesc via /dev/mdesc and does whatever it wants to do
with that image.

Your patch was also whitespace damaged by your email client.

Thank you.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
  2017-09-16  6:08 ` David Miller
@ 2017-09-18 14:23 ` Eric Saint Etienne
  2017-09-18 16:43 ` David Miller
                   ` (74 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Eric Saint Etienne @ 2017-09-18 14:23 UTC (permalink / raw)
  To: sparclinux

Thanks for the quick feedback, Dave.

Buses like PCI or USB as well as other data types are exposed in sysfs, 
not via blobs like /dev/mdesc.

Sysfs has a neat tree structure that allows to discover and browse the 
system structure. In contrast a binary blob like /dev/mdesc requires 
interpretation via a script.

The aim of this patch is to ease browsing mdesc and implement utilities 
like lshw. If you look at lshw sources, you'll see that they make a real 
huge use of sysfs, the only binary device they use is for DMI tables 
(via /dev/dmi if present, or by directly accessing mmap'ed physical 
memory otherwise)

Also, since mdesc is basically a tree it maps well to a filesystem 
structure like sysfs.

thank you.

-eric

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
  2017-09-16  6:08 ` David Miller
  2017-09-18 14:23 ` Eric Saint Etienne
@ 2017-09-18 16:43 ` David Miller
  2017-09-19  6:43 ` Eric Saint Etienne
                   ` (73 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-18 16:43 UTC (permalink / raw)
  To: sparclinux

From: Eric Saint Etienne <eric.saint.etienne@oracle.com>
Date: Mon, 18 Sep 2017 15:23:57 +0100

> The aim of this patch is to ease browsing mdesc and implement
> utilities like lshw. If you look at lshw sources, you'll see that they
> make a real huge use of sysfs, the only binary device they use is for
> DMI tables (via /dev/dmi if present, or by directly accessing mmap'ed
> physical memory otherwise)

So you're telling me that there is support for image based handling in
the tool for the sake of DMI, so the tool could therefore just as
easily handle the current mdesc export format as well.

> Also, since mdesc is basically a tree it maps well to a filesystem
> structure like sysfs.

We don't export identical information two different ways in the kernel.

We have /dev/mdesc already.

For the other cases, sysfs was done first.  It wasn't duplicating an
existing mechanism.

I still stand by my decision, sorry.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (2 preceding siblings ...)
  2017-09-18 16:43 ` David Miller
@ 2017-09-19  6:43 ` Eric Saint Etienne
  2017-09-19  6:53 ` John Paul Adrian Glaubitz
                   ` (72 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Eric Saint Etienne @ 2017-09-19  6:43 UTC (permalink / raw)
  To: sparclinux


> I still stand by my decision, sorry.
I am sorry for every Sparc users because it was a chance for them to 
easily explore and use machine description without having to install an 
external tool and a scripting language plus dependencies (potentially a 
lot of dependency). Users may also not know about /dev/mdesc whereas a 
mere "grep -ri cache /sys" would be fruitful.

Also mdesc is root accessible only. Exposing all or even just a 
selection of machine description nodes to users via sysfs provides them 
with the visibility of for instance TLBs and Caches (number, size, and 
more importantly how they are organized in the processor).

-eric

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (3 preceding siblings ...)
  2017-09-19  6:43 ` Eric Saint Etienne
@ 2017-09-19  6:53 ` John Paul Adrian Glaubitz
  2017-09-19  6:58 ` John Paul Adrian Glaubitz
                   ` (71 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19  6:53 UTC (permalink / raw)
  To: sparclinux

On 09/18/2017 06:43 PM, David Miller wrote:
>> Also, since mdesc is basically a tree it maps well to a filesystem
>> structure like sysfs.
> 
> We don't export identical information two different ways in the kernel.

I agree.

> We have /dev/mdesc already.

Is there anything that prevents us from removing it?

> For the other cases, sysfs was done first.  It wasn't duplicating an
> existing mechanism.

I don't think Eric wants to duplicate the mechanism. He rather wants
to move mdesc to sysfs which sounds like a reasonable decision.

As a user, I'd always be looking for system information below /sys,
not in a special device available in /dev/. Not supporting sysfs
for providing hardware information sounds like a step backwards
to me.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (4 preceding siblings ...)
  2017-09-19  6:53 ` John Paul Adrian Glaubitz
@ 2017-09-19  6:58 ` John Paul Adrian Glaubitz
  2017-09-19 15:55 ` Anatoly Pugachev
                   ` (70 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19  6:58 UTC (permalink / raw)
  To: sparclinux

On 09/19/2017 08:43 AM, Eric Saint Etienne wrote:
> I am sorry for every Sparc users because it was a chance for them to
> easily explore and use machine description without having to install
> an external tool and a scripting language plus dependencies (potentially
> a lot of dependency). Users may also not know about /dev/mdesc whereas
> a mere "grep -ri cache /sys" would be fruitful.

I agree and I found your argumentation very reasonable and convincing.

Users are looking for hardware information below /sysfs, not somewhere
in /dev. /dev would actually be the last location I'd ever expect to
provide hardware information.

It also shouldn't be necessary to install a special tool to be able
to parse hardware information. /dev/mdesc sounds like a relict from
the old Linux days to me which should be superceded by sysfs.

Wasn't it a goal to eventually move all system information to sysfs
and even removing the remains from /proc in the distant future as
/proc is actually the process filesystem and not for system information?

> Also mdesc is root accessible only. Exposing all or even just a selection
> of machine description nodes to users via sysfs provides them with the
> visibility of for instance TLBs and Caches (number, size, and more
> importantly how they are organized in the processor).

That's even worse. Users should be able to retrieve system information
without being the root user.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (5 preceding siblings ...)
  2017-09-19  6:58 ` John Paul Adrian Glaubitz
@ 2017-09-19 15:55 ` Anatoly Pugachev
  2017-09-19 17:31 ` David Miller
                   ` (69 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Anatoly Pugachev @ 2017-09-19 15:55 UTC (permalink / raw)
  To: sparclinux

On Mon, Sep 18, 2017 at 7:43 PM, David Miller <davem@davemloft.net> wrote:
> From: Eric Saint Etienne <eric.saint.etienne@oracle.com>
> Date: Mon, 18 Sep 2017 15:23:57 +0100
>
>> The aim of this patch is to ease browsing mdesc and implement
>> utilities like lshw. If you look at lshw sources, you'll see that they
>> make a real huge use of sysfs, the only binary device they use is for
>> DMI tables (via /dev/dmi if present, or by directly accessing mmap'ed
>> physical memory otherwise)
>
> So you're telling me that there is support for image based handling in
> the tool for the sake of DMI, so the tool could therefore just as
> easily handle the current mdesc export format as well.
>
>> Also, since mdesc is basically a tree it maps well to a filesystem
>> structure like sysfs.
>
> We don't export identical information two different ways in the kernel.
>
> We have /dev/mdesc already.
>
> For the other cases, sysfs was done first.  It wasn't duplicating an
> existing mechanism.
>
> I still stand by my decision, sorry.

David,

please, lets not make/introduce another tool for parsing /dev/mdesc,
it's so easier to use sysfs , instead of using another arch-specific
(sparc64) tool, like prtconf.

For example, virt-what, systemd-detect-virt or ansible (facts module,
virtualization) could simply look for file(s) in mounted sysfs,
instead of calling another external utility (which should be installed
before in choosen linux $distribution) or each one writting its own
internal parser for /dev/mdesc.

Thanks.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (6 preceding siblings ...)
  2017-09-19 15:55 ` Anatoly Pugachev
@ 2017-09-19 17:31 ` David Miller
  2017-09-19 17:32 ` David Miller
                   ` (68 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 17:31 UTC (permalink / raw)
  To: sparclinux

From: Eric Saint Etienne <eric.saint.etienne@oracle.com>
Date: Tue, 19 Sep 2017 07:43:51 +0100

> 
>> I still stand by my decision, sorry.
> I am sorry for every Sparc users because it was a chance for them to
> easily explore and use machine description without having to install
> an external tool and a scripting language plus dependencies
> (potentially a lot of dependency). Users may also not know about
> /dev/mdesc whereas a mere "grep -ri cache /sys" would be fruitful.
> 
> Also mdesc is root accessible only. Exposing all or even just a
> selection of machine description nodes to users via sysfs provides
> them with the visibility of for instance TLBs and Caches (number,
> size, and more importantly how they are organized in the processor).

I originally made /proc/openprom which tried to interpret all of the
properites and print them in a reasonable way, and I deeply regret
having done this.  The powerpc folks, on the other hand, just provided
the raw data and had userland tools interpret the properties and
pretty print them.

That's what guided my decision to implement /dev/mdesc.

All of that complexity and knowledge of formatting properties this way
or that has no business in the kernel, and belongs completely in
userspace.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (7 preceding siblings ...)
  2017-09-19 17:31 ` David Miller
@ 2017-09-19 17:32 ` David Miller
  2017-09-19 17:32 ` David Miller
                   ` (67 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 17:32 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Tue, 19 Sep 2017 08:53:50 +0200

> On 09/18/2017 06:43 PM, David Miller wrote:
>>> Also, since mdesc is basically a tree it maps well to a filesystem
>>> structure like sysfs.
>> 
>> We don't export identical information two different ways in the kernel.
> 
> I agree.
> 
>> We have /dev/mdesc already.
> 
> Is there anything that prevents us from removing it?

Yes, I and others have tools like mdlint that we use every day?!?!

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (8 preceding siblings ...)
  2017-09-19 17:32 ` David Miller
@ 2017-09-19 17:32 ` David Miller
  2017-09-19 17:33 ` David Miller
                   ` (66 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 17:32 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Tue, 19 Sep 2017 08:53:50 +0200

> I don't think Eric wants to duplicate the mechanism. He rather wants
> to move mdesc to sysfs which sounds like a reasonable decision.

I completely disagree, see my most recent reply to him for why.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (9 preceding siblings ...)
  2017-09-19 17:32 ` David Miller
@ 2017-09-19 17:33 ` David Miller
  2017-09-19 17:38 ` John Paul Adrian Glaubitz
                   ` (65 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 17:33 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Tue, 19 Sep 2017 08:58:06 +0200

> It also shouldn't be necessary to install a special tool to be able
> to parse hardware information. /dev/mdesc sounds like a relict from
> the old Linux days to me which should be superceded by sysfs.

The kernel has no business having all of the details of how to
interpret binary property values, what they mean, what the
most reasonable way is to format them, etc.

That's userspace.

Sparc users already make use of special tools such as 'prtconf'
and 'mdlint' already exists and works just fine.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (10 preceding siblings ...)
  2017-09-19 17:33 ` David Miller
@ 2017-09-19 17:38 ` John Paul Adrian Glaubitz
  2017-09-19 17:40 ` John Paul Adrian Glaubitz
                   ` (64 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 17:38 UTC (permalink / raw)
  To: sparclinux

On 09/19/2017 07:32 PM, David Miller wrote:
>> Is there anything that prevents us from removing it?
> 
> Yes, I and others have tools like mdlint that we use every day?!?!

This one? [1]

Otherwise I don't know of any "mdlint" tool. I just know that using
sysfs is the standard way of reading information from the kernel these
days, on all architectures.

Adrian

> [1] https://github.com/ChrisWren/mdlint

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (11 preceding siblings ...)
  2017-09-19 17:38 ` John Paul Adrian Glaubitz
@ 2017-09-19 17:40 ` John Paul Adrian Glaubitz
  2017-09-19 17:42 ` John Paul Adrian Glaubitz
                   ` (63 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 17:40 UTC (permalink / raw)
  To: sparclinux

On 09/19/2017 07:31 PM, David Miller wrote:
> All of that complexity and knowledge of formatting properties this way
> or that has no business in the kernel, and belongs completely in
> userspace.

But that's not really contradicting to the fact that this information
belongs to sysfs, not some obscure device node below /dev.

Basically every human-readable information from the kernel is provided
through sysfs these days. Why should it be different for SPARC?

I really don't think that makes any sense.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (12 preceding siblings ...)
  2017-09-19 17:40 ` John Paul Adrian Glaubitz
@ 2017-09-19 17:42 ` John Paul Adrian Glaubitz
  2017-09-19 18:04 ` David Miller
                   ` (62 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 17:42 UTC (permalink / raw)
  To: sparclinux

On 09/19/2017 07:33 PM, David Miller wrote:
> The kernel has no business having all of the details of how to
> interpret binary property values, what they mean, what the
> most reasonable way is to format them, etc.

So, you basically disagree with all the other subsystem maintainers?

> That's userspace.
> 
> Sparc users already make use of special tools such as 'prtconf'
> and 'mdlint' already exists and works just fine.

Tools that probably haven't been touched for ages. Like with SILO,
the world has moved on to more modern tools.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (13 preceding siblings ...)
  2017-09-19 17:42 ` John Paul Adrian Glaubitz
@ 2017-09-19 18:04 ` David Miller
  2017-09-19 18:07 ` David Miller
                   ` (61 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 18:04 UTC (permalink / raw)
  To: sparclinux

From: Anatoly Pugachev <matorola@gmail.com>
Date: Tue, 19 Sep 2017 18:55:52 +0300

> please, lets not make/introduce another tool for parsing /dev/mdesc,
> it's so easier to use sysfs , instead of using another arch-specific
> (sparc64) tool, like prtconf.

We have /dev/mdesc already, and there is an existing tool, mdlint.

I use it every day.

I'm not suggesting to use anything new, I'm saying use the stuff
that we have already.


^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (14 preceding siblings ...)
  2017-09-19 18:04 ` David Miller
@ 2017-09-19 18:07 ` David Miller
  2017-09-19 18:08 ` John Paul Adrian Glaubitz
                   ` (60 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 18:07 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Tue, 19 Sep 2017 19:38:38 +0200

> On 09/19/2017 07:32 PM, David Miller wrote:
>>> Is there anything that prevents us from removing it?
>> 
>> Yes, I and others have tools like mdlint that we use every day?!?!
> 
> This one? [1]
> 
> Otherwise I don't know of any "mdlint" tool. I just know that using
> sysfs is the standard way of reading information from the kernel these
> days, on all architectures.

I took the mdlint tool Solaris uses and ported it to build on Linux
so that I could test and use the /dev/mdesc driver.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (15 preceding siblings ...)
  2017-09-19 18:07 ` David Miller
@ 2017-09-19 18:08 ` John Paul Adrian Glaubitz
  2017-09-19 18:10 ` David Miller
                   ` (59 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 18:08 UTC (permalink / raw)
  To: sparclinux

On 09/19/2017 08:04 PM, David Miller wrote:> We have /dev/mdesc already, and there is an existing tool, mdlint.
Where can I find that mdlint tool?

Does it work without root privileges?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (16 preceding siblings ...)
  2017-09-19 18:08 ` John Paul Adrian Glaubitz
@ 2017-09-19 18:10 ` David Miller
  2017-09-19 18:12 ` David Miller
                   ` (58 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 18:10 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Tue, 19 Sep 2017 19:40:30 +0200

> On 09/19/2017 07:31 PM, David Miller wrote:
>> All of that complexity and knowledge of formatting properties this way
>> or that has no business in the kernel, and belongs completely in
>> userspace.
> 
> But that's not really contradicting to the fact that this information
> belongs to sysfs, not some obscure device node below /dev.
> 
> Basically every human-readable information from the kernel is provided
> through sysfs these days. Why should it be different for SPARC?

Every?

I disagree.

Properly printing openfirmware and mdesc properties requires context
(what type of bus or device is this node underneath, etc.) and
knowledge of how that property works.

The kernel has no business knowing how every current and future
property type, for every device type existing now and in the future,
should be handled.

Exporting the raw data allows having userspace decide what to do.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (17 preceding siblings ...)
  2017-09-19 18:10 ` David Miller
@ 2017-09-19 18:12 ` David Miller
  2017-09-19 18:14 ` David Miller
                   ` (57 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 18:12 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Tue, 19 Sep 2017 19:42:25 +0200

> On 09/19/2017 07:33 PM, David Miller wrote:
>> The kernel has no business having all of the details of how to
>> interpret binary property values, what they mean, what the
>> most reasonable way is to format them, etc.
> 
> So, you basically disagree with all the other subsystem maintainers?

If /dev/mdesc didn't exist, we could further delve into the details
of this situation.

But it's there, for years, and it already provides the information
that userspace needs.

>> That's userspace.
>> 
>> Sparc users already make use of special tools such as 'prtconf'
>> and 'mdlint' already exists and works just fine.
> 
> Tools that probably haven't been touched for ages. Like with SILO,
> the world has moved on to more modern tools.

Tools that work only need so many bug fixes and feature additions.

What bug in prtconf are you aware of that I haven't fixed?

What patch submitted to me for SILO or prtconf have I ignored and
not given feedback to or applied straight away?

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (18 preceding siblings ...)
  2017-09-19 18:12 ` David Miller
@ 2017-09-19 18:14 ` David Miller
  2017-09-19 18:39 ` John Paul Adrian Glaubitz
                   ` (56 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 18:14 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Tue, 19 Sep 2017 20:08:40 +0200

> Does it work without root privileges?

Depends upon what permissions and ownership the administrator decides
to set for /dev/mdesc

Which is identical to what you would get with sysfs, "file permissions"

This conversation is going nowhere, can you guys please drop this?

We're not exporting the machine desctription in a second way, period.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (19 preceding siblings ...)
  2017-09-19 18:14 ` David Miller
@ 2017-09-19 18:39 ` John Paul Adrian Glaubitz
  2017-09-19 18:40 ` David Miller
                   ` (55 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 18:39 UTC (permalink / raw)
  To: sparclinux

On 09/19/2017 08:12 PM, David Miller wrote:
> If /dev/mdesc didn't exist, we could further delve into the details
> of this situation.
> 
> But it's there, for years, and it already provides the information
> that userspace needs.

Yes, and most people probably don't even know it exists. I'm one of
Debian's sparc64 porters and I haven't heard of it before.

>> Tools that probably haven't been touched for ages. Like with SILO,
>> the world has moved on to more modern tools.
> 
> Tools that work only need so many bug fixes and feature additions.

And which are not present in any common Linux distribution that I know of.

> What bug in prtconf are you aware of that I haven't fixed?
> 
> What patch submitted to me for SILO or prtconf have I ignored and
> not given feedback to or applied straight away?

SILO is still a 32-bit application, doesn't properly support GPT partition
tables, requires a special partition layout with a small boot partition,
has a very crude and user-unfriendly boot and configuration interface
and so on.

The world has moved on from bootloaders like LILO, SILO and PALO. The
same applies for the sysfs hardware information.

And you really shouldn't take your usecase and experience as the
reference. You're a very experienced and long time user and know all
the quirks and details of the platform. Of course, you don't need
something that is user-friendly. But the majority of Linux users do.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (20 preceding siblings ...)
  2017-09-19 18:39 ` John Paul Adrian Glaubitz
@ 2017-09-19 18:40 ` David Miller
  2017-09-19 18:44 ` John Paul Adrian Glaubitz
                   ` (54 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 18:40 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Tue, 19 Sep 2017 20:39:02 +0200

> And you really shouldn't take your usecase and experience as the
> reference. You're a very experienced and long time user and know all
> the quirks and details of the platform. Of course, you don't need
> something that is user-friendly. But the majority of Linux users do.

I guess typing "prtconf -pv" is not very user friendly.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (21 preceding siblings ...)
  2017-09-19 18:40 ` David Miller
@ 2017-09-19 18:44 ` John Paul Adrian Glaubitz
  2017-09-19 18:44 ` John Paul Adrian Glaubitz
                   ` (53 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 18:44 UTC (permalink / raw)
  To: sparclinux

On 09/19/2017 08:40 PM, David Miller wrote:
>> And you really shouldn't take your usecase and experience as the
>> reference. You're a very experienced and long time user and know all
>> the quirks and details of the platform. Of course, you don't need
>> something that is user-friendly. But the majority of Linux users do.
> 
> I guess typing "prtconf -pv" is not very user friendly.

"prtconf" is not part of any Linux distribution I know of.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (22 preceding siblings ...)
  2017-09-19 18:44 ` John Paul Adrian Glaubitz
@ 2017-09-19 18:44 ` John Paul Adrian Glaubitz
  2017-09-19 19:16 ` Eric Saint Etienne
                   ` (52 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 18:44 UTC (permalink / raw)
  To: sparclinux

On 09/19/2017 08:14 PM, David Miller wrote:
>> Does it work without root privileges?
> 
> Depends upon what permissions and ownership the administrator decides
> to set for /dev/mdesc
> 
> Which is identical to what you would get with sysfs, "file permissions"
> 
> This conversation is going nowhere, can you guys please drop this?

It's not going anywhere because you are not open to discussion. You
are stuck in your opinion coming from your own personal usecase and
refuse to accept that other users have different usecases.

> We're not exporting the machine desctription in a second way, period.

Not "we", you. You are refusing to make progress and that's frustrating,
especially for all the folk from Oracle who are sending in patches all
the time.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (23 preceding siblings ...)
  2017-09-19 18:44 ` John Paul Adrian Glaubitz
@ 2017-09-19 19:16 ` Eric Saint Etienne
  2017-09-19 19:43 ` John Paul Adrian Glaubitz
                   ` (51 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Eric Saint Etienne @ 2017-09-19 19:16 UTC (permalink / raw)
  To: sparclinux


> Not "we", you. You are refusing to make progress and that's frustrating,
> especially for all the folk from Oracle who are sending in patches all
> the time.
Let's keep a cool head here, please. Nobody can and want to force Dave 
to expose mdesc on sysfs if he doesn't want to.

At the end of the day, users who want to expose mdesc on sysfs can 
download and apply the patch since it will be forever available on the 
sparclinux mailing list archives.

Thanks Dave for having spent time considering my request.

-eric


^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (24 preceding siblings ...)
  2017-09-19 19:16 ` Eric Saint Etienne
@ 2017-09-19 19:43 ` John Paul Adrian Glaubitz
  2017-09-19 20:24 ` David Miller
                   ` (50 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 19:43 UTC (permalink / raw)
  To: sparclinux

On 09/19/2017 09:16 PM, Eric Saint Etienne wrote:
>> Not "we", you. You are refusing to make progress and that's frustrating,
>> especially for all the folk from Oracle who are sending in patches all
>> the time.
>
> Let's keep a cool head here, please. Nobody can and want to force Dave to expose mdesc on sysfs if he doesn't want to.

My point is: Dave shouldn't make decisions solely based on his personal preferences
when he's making decisions that affect all users of Linux on SPARC.

We're already having some trouble to gain a reasonable amount of users and we will
not be able to make Linux on SPARC more attractive if the reference standard is
32-bit SPARC on Gentoo without any proper security support [1].

We have many Debian users who want to install Linux on their SPARC boxes. But
not all of them are hardcore experts that can deal with 15-year-old userland
tools which no one knows anymore these days and which they have to Google
search first before they can download, build and install them.
  
> At the end of the day, users who want to expose mdesc on sysfs can download
> and apply the patch since it will be forever available on the sparclinux
> mailing list archives.

Assuming that most users know how to compile their own kernel.

It's similar to the situation with the SPARC patches for GRUB. Eric has invested
lots of time and efforts to get SPARC support in GRUB back into shape so that
it works well on modern hardware with GPT partition tables, 64-bit support
and so on. Most of his patches haven't been merged to date because the GRUB
maintainers can't be bothered to have a look at them. Yes, you can grab these
patches, merge them to GRUB locally and build your own GRUB package. But that's
not what the majority of users even know how to do.

This attitude is what keeps Linux on SPARC back. If you want Linux on SPARC
to me more popular, you need it to be more user-friendly. Users expect
a certain set of features and tools these days if they want to install a Linux
distribution and that includes support for modern bootloaders and a standardized,
easily parsable system information interface and so on.

The world has moved on and users use their hardware differently these days,
that includes tools like Puppet and Ansible as Anatoly mentioned in his mail.

Adrian

> [1] https://lwn.net/Articles/724700/

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (25 preceding siblings ...)
  2017-09-19 19:43 ` John Paul Adrian Glaubitz
@ 2017-09-19 20:24 ` David Miller
  2017-09-19 20:25 ` David Miller
                   ` (49 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 20:24 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Tue, 19 Sep 2017 20:44:20 +0200

> On 09/19/2017 08:40 PM, David Miller wrote:
>>> And you really shouldn't take your usecase and experience as the
>>> reference. You're a very experienced and long time user and know all
>>> the quirks and details of the platform. Of course, you don't need
>>> something that is user-friendly. But the majority of Linux users do.
>> 
>> I guess typing "prtconf -pv" is not very user friendly.
> 
> "prtconf" is not part of any Linux distribution I know of.

davem@patience:~/src/GIT/sparc-next$ dpkg -S /usr/sbin/prtconf 
sparc-utils: /usr/sbin/prtconf

Come again?

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (26 preceding siblings ...)
  2017-09-19 20:24 ` David Miller
@ 2017-09-19 20:25 ` David Miller
  2017-09-19 20:29 ` David Miller
                   ` (48 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 20:25 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Tue, 19 Sep 2017 20:44:24 +0200

> On 09/19/2017 08:14 PM, David Miller wrote:
>>> Does it work without root privileges?
>> 
>> Depends upon what permissions and ownership the administrator decides
>> to set for /dev/mdesc
>> 
>> Which is identical to what you would get with sysfs, "file permissions"
>> 
>> This conversation is going nowhere, can you guys please drop this?
> 
> It's not going anywhere because you are not open to discussion. You
> are stuck in your opinion coming from your own personal usecase and
> refuse to accept that other users have different usecases.
> 
>> We're not exporting the machine desctription in a second way, period.
> 
> Not "we", you. You are refusing to make progress and that's frustrating,
> especially for all the folk from Oracle who are sending in patches all
> the time.

Look, there is even precedence for my decision.

We removed /proc/openprom exactly for the reasons I am giving for not
doing things that way.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (27 preceding siblings ...)
  2017-09-19 20:25 ` David Miller
@ 2017-09-19 20:29 ` David Miller
  2017-09-19 21:24 ` Anatoly Pugachev
                   ` (47 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 20:29 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Tue, 19 Sep 2017 21:43:47 +0200

> We have many Debian users who want to install Linux on their SPARC
> boxes. But not all of them are hardcore experts that can deal with
> 15-year-old userland tools which no one knows anymore these days and
> which they have to Google search first before they can download,
> build and install them.

Nobody has to download and install anything.

You are showing that you do not even know what packages exist
in Debian.

'prtconf' has been in the sparc-utils package for probably like
two decades.

I fail to see how having the proper tool in the distribution makes
things harder for users.

And, by the way, my opinions and my preferences do matter.  That's
part of what being the maintainer is all about.  Being the last choke
valve of taste and decision making for changes that go into the sparc
port.

Thank you.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (28 preceding siblings ...)
  2017-09-19 20:29 ` David Miller
@ 2017-09-19 21:24 ` Anatoly Pugachev
  2017-09-19 21:57 ` John Paul Adrian Glaubitz
                   ` (46 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Anatoly Pugachev @ 2017-09-19 21:24 UTC (permalink / raw)
  To: sparclinux

On Tue, Sep 19, 2017 at 11:29 PM, David Miller <davem@davemloft.net> wrote:
> From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Date: Tue, 19 Sep 2017 21:43:47 +0200
>
>> We have many Debian users who want to install Linux on their SPARC
>> boxes. But not all of them are hardcore experts that can deal with
>> 15-year-old userland tools which no one knows anymore these days and
>> which they have to Google search first before they can download,
>> build and install them.
>
> Nobody has to download and install anything.
>
> You are showing that you do not even know what packages exist
> in Debian.
>
> 'prtconf' has been in the sparc-utils package for probably like
> two decades.

By the way, David, what is mdlint you mentioned earlier? I'm surprised
to hear about it for the first time in my sparc linux adventure.
Google seem doesn't know anything about it, and I failed to find it
with "mdlint linux sparc" / "linux sparc wiki mdlint"
Solaris does not have it (being I'm only 10 years with solaris
starting from version 9).
Why don't we have it in sparc-utils along with prtconf and eeprom?

On the final note, why can't we have nice things together? Like proper
utility to parse MD (machine description) via binary /dev and some
kind (but user friendly) sysfs interface? Really, sysfs is so much
easier for a user (like me), let it be (even if it's incomplete) !?
Linux kernel is full of such examples, where device access is done via
/dev and auxiliary information is available via sysfs.

Thanks!

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (29 preceding siblings ...)
  2017-09-19 21:24 ` Anatoly Pugachev
@ 2017-09-19 21:57 ` John Paul Adrian Glaubitz
  2017-09-19 22:02 ` John Paul Adrian Glaubitz
                   ` (45 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 21:57 UTC (permalink / raw)
  To: sparclinux

On 09/19/2017 10:24 PM, David Miller wrote:
> davem@patience:~/src/GIT/sparc-next$ dpkg -S /usr/sbin/prtconf 
> sparc-utils: /usr/sbin/prtconf
> 
> Come again?

David, seriously, are you arguing about Debian packages with me?

sparc-utils is part of the *unreleased* distribution because *I*
put it there. *unreleased* is *not* an official part of Debian.

sparc-utils is *not* part of Debian unstable.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (30 preceding siblings ...)
  2017-09-19 21:57 ` John Paul Adrian Glaubitz
@ 2017-09-19 22:02 ` John Paul Adrian Glaubitz
  2017-09-19 22:03 ` Kjetil Oftedal
                   ` (44 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 22:02 UTC (permalink / raw)
  To: sparclinux

On 09/19/2017 10:29 PM, David Miller wrote:
> You are showing that you do not even know what packages exist
> in Debian.

No, you're the one who is not up the current status quo.

> 'prtconf' has been in the sparc-utils package for probably like
> two decades.

No, it isn't. Debian on sparc does no longer exist and "sparc-utils"
is a package with the architectures "sparc" and "sparc64". The former
is no longer part of Debian, the latter is part of Debian Ports.

Any package which is not building on the release architectures cannot
exist anywhere but in Debian *unreleased* and any package there is
not part of Debian and completely unsupported. It merely exists
there because *I* put it there.

> I fail to see how having the proper tool in the distribution makes
> things harder for users.

Because the proper tool is *not* part of the distribution.

> And, by the way, my opinions and my preferences do matter.  That's
> part of what being the maintainer is all about.  Being the last choke
> valve of taste and decision making for changes that go into the sparc
> port.

No, I wholeheartedly disagree. This is how projects are forked and
this is how projects like XFree86, OSS, cdrecord and so on went
down the drain. Because one or single maintainers thought their
opinion is all that counts.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (31 preceding siblings ...)
  2017-09-19 22:02 ` John Paul Adrian Glaubitz
@ 2017-09-19 22:03 ` Kjetil Oftedal
  2017-09-19 22:05 ` John Paul Adrian Glaubitz
                   ` (43 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Kjetil Oftedal @ 2017-09-19 22:03 UTC (permalink / raw)
  To: sparclinux

On 19/09/2017, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> On 09/19/2017 10:24 PM, David Miller wrote:
>> davem@patience:~/src/GIT/sparc-next$ dpkg -S /usr/sbin/prtconf
>> sparc-utils: /usr/sbin/prtconf
>>
>> Come again?
>
> David, seriously, are you arguing about Debian packages with me?
>
> sparc-utils is part of the *unreleased* distribution because *I*
> put it there. *unreleased* is *not* an official part of Debian.
>
> sparc-utils is *not* part of Debian unstable.
>
> Adrian
>

Actually, sparc-utils was a part of wheezy/stable before Debian decided
to drop the official SPARC port.

-
Kjetil

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (32 preceding siblings ...)
  2017-09-19 22:03 ` Kjetil Oftedal
@ 2017-09-19 22:05 ` John Paul Adrian Glaubitz
  2017-09-19 22:06 ` David Miller
                   ` (42 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 22:05 UTC (permalink / raw)
  To: sparclinux

On 09/20/2017 12:03 AM, Kjetil Oftedal wrote:
> Actually, sparc-utils was a part of wheezy/stable before Debian decided
> to drop the official SPARC port.

Yes, I retrieved it from there and made it available for sparc64. I also had
to patch it because it wouldn't work on sparc64 [1].

But we're not talking about history, we're talking about current software.

Adrian

> [1] http://ftp.ports.debian.org/debian-ports/pool-sparc64/main/s/sparc-utils/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (33 preceding siblings ...)
  2017-09-19 22:05 ` John Paul Adrian Glaubitz
@ 2017-09-19 22:06 ` David Miller
  2017-09-19 22:07 ` David Miller
                   ` (41 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 22:06 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Tue, 19 Sep 2017 23:57:53 +0200

> On 09/19/2017 10:24 PM, David Miller wrote:
>> davem@patience:~/src/GIT/sparc-next$ dpkg -S /usr/sbin/prtconf 
>> sparc-utils: /usr/sbin/prtconf
>> 
>> Come again?
> 
> David, seriously, are you arguing about Debian packages with me?

As long as you keep spouting falsehoods, yes I will.

> sparc-utils is part of the *unreleased* distribution because *I*
> put it there. *unreleased* is *not* an official part of Debian.
> 
> sparc-utils is *not* part of Debian unstable.

Come again?

davem@patience:~/src/GIT/sparc-next$ cat /etc/apt/sources.list
# 

# deb cdrom:[Debian GNU/Linux testing _Wheezy_ - Official Snapshot sparc NETINST Binary-1 20121216-21:35]/ wheezy main

deb http://debian.osuosl.org/debian/ wheezy main
deb-src http://debian.osuosl.org/debian/ wheezy main

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (34 preceding siblings ...)
  2017-09-19 22:06 ` David Miller
@ 2017-09-19 22:07 ` David Miller
  2017-09-19 22:08 ` David Miller
                   ` (40 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 22:07 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Wed, 20 Sep 2017 00:02:20 +0200

> On 09/19/2017 10:29 PM, David Miller wrote:
>> You are showing that you do not even know what packages exist
>> in Debian.
> 
> No, you're the one who is not up the current status quo.
> 
>> 'prtconf' has been in the sparc-utils package for probably like
>> two decades.
> 
> No, it isn't. Debian on sparc does no longer exist and "sparc-utils"
> is a package with the architectures "sparc" and "sparc64". The former
> is no longer part of Debian, the latter is part of Debian Ports.

If the package got removed from 'main' repository, that's not something
I did.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (35 preceding siblings ...)
  2017-09-19 22:07 ` David Miller
@ 2017-09-19 22:08 ` David Miller
  2017-09-19 22:09 ` John Paul Adrian Glaubitz
                   ` (39 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 22:08 UTC (permalink / raw)
  To: sparclinux

From: Kjetil Oftedal <oftedal@gmail.com>
Date: Wed, 20 Sep 2017 00:03:30 +0200

> On 19/09/2017, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
>> On 09/19/2017 10:24 PM, David Miller wrote:
>>> davem@patience:~/src/GIT/sparc-next$ dpkg -S /usr/sbin/prtconf
>>> sparc-utils: /usr/sbin/prtconf
>>>
>>> Come again?
>>
>> David, seriously, are you arguing about Debian packages with me?
>>
>> sparc-utils is part of the *unreleased* distribution because *I*
>> put it there. *unreleased* is *not* an official part of Debian.
>>
>> sparc-utils is *not* part of Debian unstable.
>>
>> Adrian
>>
> 
> Actually, sparc-utils was a part of wheezy/stable before Debian decided
> to drop the official SPARC port.

What a relief, some sanity, _THANK_ _YOU_.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (36 preceding siblings ...)
  2017-09-19 22:08 ` David Miller
@ 2017-09-19 22:09 ` John Paul Adrian Glaubitz
  2017-09-19 22:12 ` David Miller
                   ` (38 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 22:09 UTC (permalink / raw)
  To: sparclinux

On 09/20/2017 12:06 AM, David Miller wrote:
> Come again?
> 
> davem@patience:~/src/GIT/sparc-next$ cat /etc/apt/sources.list
> # 
> 
> # deb cdrom:[Debian GNU/Linux testing _Wheezy_ - Official Snapshot sparc NETINST Binary-1 20121216-21:35]/ wheezy main

Are you actually being serious. You are talking about something
that has been completely dead and unsupported for years.

Are you seriously recommending SPARC users to install an ancient
release of Debian stable?

Do you think that people who buy a $100,000 SPARC server nowadays
install Debian Wheezy on it?

Come, on.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (37 preceding siblings ...)
  2017-09-19 22:09 ` John Paul Adrian Glaubitz
@ 2017-09-19 22:12 ` David Miller
  2017-09-19 22:13 ` David Miller
                   ` (37 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 22:12 UTC (permalink / raw)
  To: sparclinux

From: David Miller <davem@davemloft.net>
Date: Tue, 19 Sep 2017 15:08:28 -0700 (PDT)

> From: Kjetil Oftedal <oftedal@gmail.com>
> Date: Wed, 20 Sep 2017 00:03:30 +0200
> 
>> On 19/09/2017, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
>>> On 09/19/2017 10:24 PM, David Miller wrote:
>>>> davem@patience:~/src/GIT/sparc-next$ dpkg -S /usr/sbin/prtconf
>>>> sparc-utils: /usr/sbin/prtconf
>>>>
>>>> Come again?
>>>
>>> David, seriously, are you arguing about Debian packages with me?
>>>
>>> sparc-utils is part of the *unreleased* distribution because *I*
>>> put it there. *unreleased* is *not* an official part of Debian.
>>>
>>> sparc-utils is *not* part of Debian unstable.
>>>
>>> Adrian
>>>
>> 
>> Actually, sparc-utils was a part of wheezy/stable before Debian decided
>> to drop the official SPARC port.
> 
> What a relief, some sanity, _THANK_ _YOU_.

And btw this really sounds like a _disincentive_ to use the current sparc64
debian port, if useful utilities are being removed from the primary sparc64
set of packages like this.

I keep hearing about how I am getting in the way of users making use of
the sparc64 port.

But honestly I haven't done things like remove core utilities or anything
like that.

The worst thing I might have done is given it a lot of bad press because
I still to this day thing that using a default of 64-bits for all userland
utilities is a huge mistake.  And that for performance reasons 32-bit
should be the default, and things like databases and what--have-you should
be built 64-bit on a case by case basis.

This is why I won't upgrade and I'll keep kicking the tires on my ancient
debian sparc installs.

Maybe other people see things the similarly to how I do, and share
some of my opinions, and that's at least part of the real reason
sparc64/debian doesn't have a lot of uptake.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (38 preceding siblings ...)
  2017-09-19 22:12 ` David Miller
@ 2017-09-19 22:13 ` David Miller
  2017-09-19 22:13 ` John Paul Adrian Glaubitz
                   ` (36 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 22:13 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Wed, 20 Sep 2017 00:09:42 +0200

> On 09/20/2017 12:06 AM, David Miller wrote:
>> Come again?
>> 
>> davem@patience:~/src/GIT/sparc-next$ cat /etc/apt/sources.list
>> # 
>> 
>> # deb cdrom:[Debian GNU/Linux testing _Wheezy_ - Official Snapshot sparc NETINST Binary-1 20121216-21:35]/ wheezy main
> 
> Are you actually being serious. You are talking about something
> that has been completely dead and unsupported for years.
> 
> Are you seriously recommending SPARC users to install an ancient
> release of Debian stable?
> 
> Do you think that people who buy a $100,000 SPARC server nowadays
> install Debian Wheezy on it?

I'm suggesting that what was sane and done properly in the past,
having the sparc utilities people expect in the main repository,
has aparently been undone.

I didn't do that, someone else did.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (39 preceding siblings ...)
  2017-09-19 22:13 ` David Miller
@ 2017-09-19 22:13 ` John Paul Adrian Glaubitz
  2017-09-19 22:15 ` David Miller
                   ` (35 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 22:13 UTC (permalink / raw)
  To: sparclinux

On 09/20/2017 12:08 AM, David Miller wrote:
>> Actually, sparc-utils was a part of wheezy/stable before Debian decided
>> to drop the official SPARC port.
> 
> What a relief, some sanity, _THANK_ _YOU_.

You are aware of the fact that Gentoo is about to completely remove
support for sparc these days? [1] You want to just run Wheezy on your
boxes then?

Adrian

> [1] https://archives.gentoo.org/gentoo-project/message/4e30b4d5db8da87774e911f738bd5774

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (40 preceding siblings ...)
  2017-09-19 22:13 ` John Paul Adrian Glaubitz
@ 2017-09-19 22:15 ` David Miller
  2017-09-19 22:16 ` John Paul Adrian Glaubitz
                   ` (34 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-19 22:15 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Wed, 20 Sep 2017 00:13:43 +0200

> On 09/20/2017 12:08 AM, David Miller wrote:
>>> Actually, sparc-utils was a part of wheezy/stable before Debian decided
>>> to drop the official SPARC port.
>> 
>> What a relief, some sanity, _THANK_ _YOU_.
> 
> You are aware of the fact that Gentoo is about to completely remove
> support for sparc these days? [1] You want to just run Wheezy on your
> boxes then?

At least it has the packages that should be there by default.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (41 preceding siblings ...)
  2017-09-19 22:15 ` David Miller
@ 2017-09-19 22:16 ` John Paul Adrian Glaubitz
  2017-09-19 22:25 ` John Paul Adrian Glaubitz
                   ` (33 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 22:16 UTC (permalink / raw)
  To: sparclinux

On 09/20/2017 12:13 AM, John Paul Adrian Glaubitz wrote:
> You are aware of the fact that Gentoo is about to completely remove
> support for sparc these days? [1] You want to just run Wheezy on your
> boxes then?

For the record, they already pulled the plug:

> https://gitweb.gentoo.org/repo/gentoo.git/commit/?idµ901d8f716555a1479f12313a2925fcadd177a9

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (42 preceding siblings ...)
  2017-09-19 22:16 ` John Paul Adrian Glaubitz
@ 2017-09-19 22:25 ` John Paul Adrian Glaubitz
  2017-09-22 18:40 ` Anatoly Pugachev
                   ` (32 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-19 22:25 UTC (permalink / raw)
  To: sparclinux

On 09/20/2017 12:15 AM, David Miller wrote:
> At least it has the packages that should be there by default.

I don't think you really understand why sparc-utils is no longer part
of Debian unstable. And, as already mentioned, Gentoo has effectively
killed off sparc support.

Users currently have only three options:

 * Linux for SPARC
 * Oracle Linux for SPARC
 * Debian unstable sparc64

All of these are pure 64-bit builds. There are no more 32-bit SPARC
distributions left. You can, if you really want to, bootstrap your
own Debian sparc (32-bit) using rebootstrap [1].

Adrian

> [1] https://wiki.debian.org/HelmutGrohne/rebootstrap

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (43 preceding siblings ...)
  2017-09-19 22:25 ` John Paul Adrian Glaubitz
@ 2017-09-22 18:40 ` Anatoly Pugachev
  2017-09-23  1:35 ` David Miller
                   ` (31 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Anatoly Pugachev @ 2017-09-22 18:40 UTC (permalink / raw)
  To: sparclinux

On Wed, Sep 20, 2017 at 12:24 AM, Anatoly Pugachev <matorola@gmail.com> wrote:
> On Tue, Sep 19, 2017 at 11:29 PM, David Miller <davem@davemloft.net> wrote:
>> 'prtconf' has been in the sparc-utils package for probably like
>> two decades.
>
> By the way, David, what is mdlint you mentioned earlier? I'm surprised
> to hear about it for the first time in my sparc linux adventure.
> Google seem doesn't know anything about it, and I failed to find it
> with "mdlint linux sparc" / "linux sparc wiki mdlint"
> Solaris does not have it (being I'm only 10 years with solaris
> starting from version 9).
> Why don't we have it in sparc-utils along with prtconf and eeprom?

David,

is it possible to download mdlint somewhere ?

Thanks!

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (44 preceding siblings ...)
  2017-09-22 18:40 ` Anatoly Pugachev
@ 2017-09-23  1:35 ` David Miller
  2017-09-23  6:14 ` John Paul Adrian Glaubitz
                   ` (30 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-23  1:35 UTC (permalink / raw)
  To: sparclinux

From: Anatoly Pugachev <matorola@gmail.com>
Date: Fri, 22 Sep 2017 21:40:42 +0300

> On Wed, Sep 20, 2017 at 12:24 AM, Anatoly Pugachev <matorola@gmail.com> wrote:
>> On Tue, Sep 19, 2017 at 11:29 PM, David Miller <davem@davemloft.net> wrote:
>>> 'prtconf' has been in the sparc-utils package for probably like
>>> two decades.
>>
>> By the way, David, what is mdlint you mentioned earlier? I'm surprised
>> to hear about it for the first time in my sparc linux adventure.
>> Google seem doesn't know anything about it, and I failed to find it
>> with "mdlint linux sparc" / "linux sparc wiki mdlint"
>> Solaris does not have it (being I'm only 10 years with solaris
>> starting from version 9).
>> Why don't we have it in sparc-utils along with prtconf and eeprom?
> 
> David,
> 
> is it possible to download mdlint somewhere ?

It was part of the opensolaris sources, I ported it locally myself
so that it would build and work on Linux.

I do not know where you can download it, and I'm probably not allowed
to redistribute my modified version of the sources.

Sorry.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (45 preceding siblings ...)
  2017-09-23  1:35 ` David Miller
@ 2017-09-23  6:14 ` John Paul Adrian Glaubitz
  2017-09-23 16:53 ` David Miller
                   ` (29 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: John Paul Adrian Glaubitz @ 2017-09-23  6:14 UTC (permalink / raw)
  To: sparclinux

On 09/23/2017 03:35 AM, David Miller wrote:
> It was part of the opensolaris sources, I ported it locally myself
> so that it would build and work on Linux.
> 
> I do not know where you can download it, and I'm probably not allowed
> to redistribute my modified version of the sources.

So, you are eagerly defending the use of /dev/mdesc and claim there is
no need for anyone to have a sysfs interface because people can use tools
like mdlint only to disclose later that mdlint not available anywhere
because it is effectively proprietary.

OK.

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (46 preceding siblings ...)
  2017-09-23  6:14 ` John Paul Adrian Glaubitz
@ 2017-09-23 16:53 ` David Miller
  2017-09-23 19:34 ` Frans van Berckel
                   ` (28 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-23 16:53 UTC (permalink / raw)
  To: sparclinux

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Sat, 23 Sep 2017 08:14:41 +0200

> On 09/23/2017 03:35 AM, David Miller wrote:
>> It was part of the opensolaris sources, I ported it locally myself
>> so that it would build and work on Linux.
>> 
>> I do not know where you can download it, and I'm probably not allowed
>> to redistribute my modified version of the sources.
> 
> So, you are eagerly defending the use of /dev/mdesc and claim there is
> no need for anyone to have a sysfs interface because people can use tools
> like mdlint only to disclose later that mdlint not available anywhere
> because it is effectively proprietary.
> 
> OK.

The tool is quite easy to write.  Would you like me to write such a
tool in a day or two?  It would look very similar to what the mdesc
sysfs kernel patch looked like, in fact much of the code would look
identical.

The problem with the Linux/sparc port is resources, I'm the only
maintainer and I devote all of the spare time I have for kernel patch
review.

I know you really want to prove me wrong, and that this is very
important to you for some reason.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (47 preceding siblings ...)
  2017-09-23 16:53 ` David Miller
@ 2017-09-23 19:34 ` Frans van Berckel
  2017-09-24 16:23 ` Wim Coekaerts
                   ` (27 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Frans van Berckel @ 2017-09-23 19:34 UTC (permalink / raw)
  To: sparclinux

On Fri, 2017-09-22 at 21:40 +0300, Anatoly Pugachev wrote:
> On Wed, Sep 20, 2017 at 12:24 AM, Anatoly Pugachev
> <matorola@gmail.com> wrote:

> David,
> 
> is it possible to download mdlint somewhere ?

I love advanced searching with Google ...

hypervisor-opensparc/src/support/

..
aschk
mdgen
mdlint
stabs
Makefile

https://tinyurl.com/yb5r7s3u

Thanks,


Frans van Berckel

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (48 preceding siblings ...)
  2017-09-23 19:34 ` Frans van Berckel
@ 2017-09-24 16:23 ` Wim Coekaerts
  2017-09-24 20:54 ` Eric Saint Etienne
                   ` (26 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Wim Coekaerts @ 2017-09-24 16:23 UTC (permalink / raw)
  To: sparclinux

Let me dig up the source and see.

On 9/22/17, 6:35 PM, David Miller wrote:
> From: Anatoly Pugachev <matorola@gmail.com>
> Date: Fri, 22 Sep 2017 21:40:42 +0300
>
>> On Wed, Sep 20, 2017 at 12:24 AM, Anatoly Pugachev <matorola@gmail.com> wrote:
>>> On Tue, Sep 19, 2017 at 11:29 PM, David Miller <davem@davemloft.net> wrote:
>>>> 'prtconf' has been in the sparc-utils package for probably like
>>>> two decades.
>>> By the way, David, what is mdlint you mentioned earlier? I'm surprised
>>> to hear about it for the first time in my sparc linux adventure.
>>> Google seem doesn't know anything about it, and I failed to find it
>>> with "mdlint linux sparc" / "linux sparc wiki mdlint"
>>> Solaris does not have it (being I'm only 10 years with solaris
>>> starting from version 9).
>>> Why don't we have it in sparc-utils along with prtconf and eeprom?
>> David,
>>
>> is it possible to download mdlint somewhere ?
> It was part of the opensolaris sources, I ported it locally myself
> so that it would build and work on Linux.
>
> I do not know where you can download it, and I'm probably not allowed
> to redistribute my modified version of the sources.
>
> Sorry.
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (49 preceding siblings ...)
  2017-09-24 16:23 ` Wim Coekaerts
@ 2017-09-24 20:54 ` Eric Saint Etienne
  2017-09-25 21:33 ` David Miller
                   ` (25 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Eric Saint Etienne @ 2017-09-24 20:54 UTC (permalink / raw)
  To: sparclinux


> The problem with the Linux/sparc port is resources, I'm the only
> maintainer and I devote all of the spare time I have for kernel patch
> review.

Maybe it does have something to do with being maintainer of so many subsystems:
- Sparc arch
- Sparc drivers
- General Networking
- IPSEC
- Networking IPv4/IPv6
- Crypto API
- Kernel probes
- IDE subsystem

in addition to your daily job and having a life.

I'd be overloaded with only one of these subsystem to maintain, so I easily imagine that you've got very little time to devote/spare to Sparc.

-eric

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (50 preceding siblings ...)
  2017-09-24 20:54 ` Eric Saint Etienne
@ 2017-09-25 21:33 ` David Miller
  2017-09-29  9:13 ` Eric Saint Etienne
                   ` (24 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-09-25 21:33 UTC (permalink / raw)
  To: sparclinux


Ok Eric, I've had a change of mind.  I've decided to let this mdesc
sysfs change go in.

Please resubmit the patch so we can review it for any other issues.

Thank you.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (51 preceding siblings ...)
  2017-09-25 21:33 ` David Miller
@ 2017-09-29  9:13 ` Eric Saint Etienne
  2017-09-29  9:14 ` Eric Saint-Etienne
                   ` (23 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Eric Saint Etienne @ 2017-09-29  9:13 UTC (permalink / raw)
  To: sparclinux


> Ok Eric, I've had a change of mind.  I've decided to let this mdesc
> sysfs change go in.
>
> Please resubmit the patch so we can review it for any other issues.
>
> Thank you.

Thank you, that's good news.
I'll resubmit the patch today.

-eric

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (52 preceding siblings ...)
  2017-09-29  9:13 ` Eric Saint Etienne
@ 2017-09-29  9:14 ` Eric Saint-Etienne
  2017-12-01 17:15 ` Eric Saint Etienne
                   ` (22 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Eric Saint-Etienne @ 2017-09-29  9:14 UTC (permalink / raw)
  To: sparclinux

To get a snapshot as complete as possible of what the system is composed of,
this commit adds the ability to browse machine description from sysfs.

This commit eases porting of user-space utilities that exist on other architectures.

Whenever the HV changes machine description content, sysfs will be re-populated.
This is done almost atomically by swapping the old mdesc sysfs folder with the
new one. While the tree under the new folder is being created, reading from
/sys/firmware/mdesc will return EAGAIN. That way userspace programs will not see
stale content in /sys/firmware/mdesc

Signed-off-by: Eric Saint Etienne <eric.saint.etienne@oracle.com>
Reviewed-by: David Aldridge <david.j.aldridge@oracle.com>
---
 arch/sparc/Kconfig              |    8 +
 arch/sparc/kernel/Makefile      |    3 +
 arch/sparc/kernel/mdesc.c       |    8 +
 arch/sparc/kernel/mdesc_sysfs.c |  831 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 850 insertions(+), 0 deletions(-)
 create mode 100644 arch/sparc/kernel/mdesc_sysfs.c

diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index a4a6261..4e2b640 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -470,6 +470,14 @@ config UBOOT_ENTRY_ADDR
 endmenu
 endif
 
+config MDESC_SYSFS
+	bool "Maps machine description to sysfs"
+	depends on SPARC64
+	default y
+	---help---
+	  If you say Y here, the directed acyclic graph described in the machine
+	  description will be expanded and made available in /sys/firmware/mdesc
+
 endmenu
 
 menu "Bus options (PCI etc.)"
diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile
index aac6098..328eb9c 100644
--- a/arch/sparc/kernel/Makefile
+++ b/arch/sparc/kernel/Makefile
@@ -118,3 +118,6 @@ obj-$(CONFIG_SPARC64)	+= $(pc--y)
 
 obj-$(CONFIG_UPROBES)	+= uprobes.o
 obj-$(CONFIG_SPARC64)	+= jump_label.o
+
+obj-$(CONFIG_MDESC_SYSFS) += mdesc_sysfs.o
+
diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel/mdesc.c
index fa466ce..75db846 100644
--- a/arch/sparc/kernel/mdesc.c
+++ b/arch/sparc/kernel/mdesc.c
@@ -87,6 +87,10 @@ struct md_node_ops {
 	mdesc_node_match_f	node_match;
 };
 
+#ifdef MDESC_SYSFS
+int mdesc_sysfs_populate(void);
+#endif
+
 static int get_vdev_port_node_info(struct mdesc_handle *md, u64 node,
 				   union md_node_info *node_info);
 static void rel_vdev_port_node_info(union md_node_info *node_info);
@@ -523,6 +527,10 @@ void mdesc_update(void)
 	cur_mdesc = hp;
 	spin_unlock_irqrestore(&mdesc_lock, flags);
 
+#ifdef MDESC_SYSFS
+	mdesc_sysfs_populate();
+#endif
+
 	mdesc_notify_clients(orig_hp, hp);
 
 	spin_lock_irqsave(&mdesc_lock, flags);
diff --git a/arch/sparc/kernel/mdesc_sysfs.c b/arch/sparc/kernel/mdesc_sysfs.c
new file mode 100644
index 0000000..f2e048c
--- /dev/null
+++ b/arch/sparc/kernel/mdesc_sysfs.c
@@ -0,0 +1,831 @@
+/*
+ * mdesc_sysfs.c - Maps machine description DAG to sysfs
+ *
+ * Copyright (c) 2017 Oracle and/or its affiliates. All rights reserved.
+ * Author: Eric Saint-Etienne
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING.  If not, write to
+ * the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139,
+ * USA.
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <asm/mdesc.h>
+
+#define MDESC_SYSFS_TOO_LARGE "Error: Not enough space to output the data, retrieve it from /dev/mdesc instead."
+
+/*
+ * Machine Description is described in slides 37-39 here:
+ * http://www.oracle.com/technetwork/systems/opensparc/2008-oct-opensparc-slide-cast-09-mw-1539018.html
+ *
+ * It is composed of three main sections decribed by the following mdesc header.
+ * Since these blocks are contiguous, describing their size is sufficient to
+ * precisely locate them within the mdesc blob.
+ *
+ * - The NODE block contains the nodes of the directed acyclic graph (DAG)
+ * - The NAME block contains names of properties referred to by the DAG nodes
+ * - The DATA block contains values for the properties: strings and binary data
+ *
+ * A public specification of mdesc is available online at:
+ * https://kenai.com/downloads/hypervisor/hypervisor-api-3.0draft7.pdf
+ */
+struct mdesc_hdr {
+	u32	version; /* Transport version */
+	u32	node_sz; /* node block size */
+	u32	name_sz; /* name block size */
+	u32	data_sz; /* data block size */
+} __aligned(16)__;
+
+struct mdesc_elem {
+	u8	tag;
+#define MD_LIST_END	0x00
+#define MD_NODE		0x4e
+#define MD_NODE_END	0x45
+#define MD_NOOP		0x20
+#define MD_PROP_ARC	0x61
+#define MD_PROP_VAL	0x76
+#define MD_PROP_STR	0x73
+#define MD_PROP_DATA	0x64
+	u8	name_len;
+	u16	resv;
+	u32	name_offset;
+	union {
+		struct {
+			u32	data_len;
+			u32	data_offset;
+		} data;
+		u64	val;
+	} d;
+};
+
+struct mdesc_mem_ops {
+	struct mdesc_handle *(*alloc)(unsigned int mdesc_size);
+	void (*free)(struct mdesc_handle *handle);
+};
+
+struct mdesc_handle {
+	struct list_head     list;
+	struct mdesc_mem_ops *mops;
+	void                 *self_base;
+	atomic_t             refcnt;
+	unsigned int         handle_size;
+	struct mdesc_hdr     mdesc;
+};
+
+/*
+ * The following 3 functions return a pointer of the right type to the
+ * 3 main mdesc blocks
+ */
+
+static inline struct mdesc_elem *node_block(struct mdesc_hdr *mdesc)
+{
+	return (struct mdesc_elem *) (mdesc + 1);
+}
+
+static inline void *name_block(struct mdesc_hdr *mdesc)
+{
+	return ((void *) node_block(mdesc)) + mdesc->node_sz;
+}
+
+static inline void *data_block(struct mdesc_hdr *mdesc)
+{
+	return ((void *) name_block(mdesc)) + mdesc->name_sz;
+}
+
+/*
+ * Dynamically allocates the right amount of characters to format according
+ * to the printf-like format specified in "fmt".
+ * "*buf" is allocated and filled.
+ *
+ * Return 0 upon success
+ */
+static int alloc_sprintf(char **buf, const char *fmt, ...)
+{
+	va_list args;
+	size_t len, actual;
+
+	va_start(args, fmt);
+	len = vsnprintf(NULL, 0, fmt, args);
+	va_end(args);
+
+	*buf = kmalloc(len+1, GFP_KERNEL);
+	if (!*buf)
+		return -ENOMEM;
+
+	va_start(args, fmt);
+	actual = vscnprintf(*buf, len + 1, fmt, args);
+	va_end(args);
+
+	if (actual != len) {
+		kfree(*buf);
+		*buf = NULL;
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+/*
+ * Flags used with the following formatting functions that modify the way
+ * node names are formatted
+ */
+#define FORMAT_APPEND    0x01
+#define FORMAT_USE_INDEX 0x02
+
+/*
+ * Take an arc node in "ep" and format it using the "id" field as to avoid
+ * collision when adding to sysfs.
+ * Ex: multiple "cpu" nodes in the same folder will be named: "0", "1"...
+ *
+ * When FORMAT_APPEND is used, the names will become: "cpu0", "cpu1"...
+ * The formatted string is found in *formatted, to be freed by the caller
+ *
+ * Return 0 upon success
+ */
+static int format_using_id(struct mdesc_handle *hp,
+			   struct mdesc_elem *ep,
+			   char const *name,
+			   char **formatted,
+			   unsigned int flags,
+			   unsigned int index,
+			   unsigned int total)
+{
+	const u64 *prop_id = mdesc_get_property(hp, ep->d.val, "id", NULL);
+
+	if (!prop_id) {
+		pr_err("mdesc %s doesn't have a property \"id\"\n", name);
+		return -ENOENT;
+	}
+
+	if (flags & FORMAT_APPEND)
+		return alloc_sprintf(formatted, "%s%lld", name, *prop_id);
+
+	return alloc_sprintf(formatted, "%lld", *prop_id);
+}
+
+/*
+ * Take an arc node in "ep" and format it using the "name" field as to avoid
+ * collision when adding to sysfs.
+ * Ex: multiple "virtual-device" nodes in the same folder will be named:
+ * "disk", "network"...
+ *
+ * When FORMAT_APPEND is used: "virtual-device-disk", virtual-device-network"...
+ *
+ * Because the "name" field is not guaranteed to be unique, one can use the
+ * flag FORMAT_USE_INDEX: "virtual-device0-disk", virtual-device1-network"...
+ * In this case "index" is used.
+ *
+ * The formatted string is found in *formatted, to be freed by the caller
+ *
+ * Return 0 upon success
+ */
+static int format_using_name(struct mdesc_handle *hp,
+			     struct mdesc_elem *ep,
+			     const char *name,
+			     char **formatted,
+			     unsigned int flags,
+			     unsigned int index,
+			     unsigned int total)
+{
+	const char *prop_name = mdesc_get_property(hp, ep->d.val, "name", NULL);
+
+	if (!prop_name) {
+		pr_err("mdesc %s doesn't have a property \"name\"\n", name);
+		return -ENOENT;
+	}
+
+	if (flags & FORMAT_APPEND) {
+		if (flags & FORMAT_USE_INDEX)
+			return alloc_sprintf(formatted, "%s%d_%s",
+					     name, index, prop_name);
+		else
+			return alloc_sprintf(formatted, "%s_%s",
+					     name, prop_name);
+	}
+
+	if (flags & FORMAT_USE_INDEX)
+		return alloc_sprintf(formatted, "%s%d", prop_name, index);
+	else
+		return alloc_sprintf(formatted, "%s", prop_name);
+}
+
+/*
+ * Default formatting used in format_name() for arcs nodes.
+ * Called when we find multiple arcs with the same name for which no
+ * formatting is specified in format_nodes array.
+ * This default formatting guarantees uniqueness because it is using the node
+ * index in the mdesc nodes array
+ */
+static char *format_name_fallback(struct mdesc_handle *hp,
+				  struct mdesc_elem *ep,
+				  const char *name,
+				  unsigned int    index,
+				  unsigned int    total)
+{
+	char *formatted = NULL;
+	int err;
+
+	err = alloc_sprintf(&formatted, "%s_0x%x", name, ep->d.val);
+	return err ? NULL : formatted;
+}
+
+struct format_node {
+	char	*name;
+	int	(*format)(struct mdesc_handle*, struct mdesc_elem*, const char*,
+			char**, unsigned int, unsigned int, unsigned int);
+	unsigned int flags;
+};
+
+struct format_node format_nodes[] = {
+#define FORMAT_APPEND_USE_INDEX (FORMAT_APPEND | FORMAT_USE_INDEX)
+	{ "virtual-device",       format_using_name, FORMAT_APPEND_USE_INDEX },
+	{ "domain-services-port", format_using_id,   FORMAT_APPEND },
+	{ "virtual-device-port",  format_using_id,   FORMAT_APPEND },
+	{ "channel-endpoint",     format_using_id,   FORMAT_APPEND },
+	{ "cpu",                  format_using_id,   FORMAT_APPEND },
+	{ NULL, NULL, 0 }
+};
+
+/*
+ * Format the name of an arc node according to the table "format_nodes".
+ * If no entry is found for the arc node in "ep", it falls back to using
+ * format_name_fallback()
+ * Returns the formatted string, to be freed by the caller
+ */
+static char *format_name(struct mdesc_handle *hp,
+			 struct mdesc_elem *ep,
+			 const char *name,
+			 int    index,
+			 int    total)
+{
+	struct format_node *fn;
+	char   *formatted = NULL;
+	bool   found = false;
+	int    err = 0;
+
+	for (fn = format_nodes; fn->name; fn++) {
+		if (strcmp(fn->name, name))
+			continue;
+		err = fn->format(hp, ep, name, &formatted,
+				 fn->flags, index, total);
+		found = true;
+		break;
+	}
+
+	if (!found && (total != 1)) {
+		/*
+		 * there's no handler for this node and we've got more
+		 * than one so we format it by appending the index
+		 * (by order of appearance)
+		 */
+		err = alloc_sprintf(&formatted, "%s%lld", name, index);
+	}
+
+	if (err)
+		return format_name_fallback(hp, ep, name, index, total);
+
+	return formatted;
+}
+
+/*
+ * Takes an arc node in "ep" and create a folder in sysfs with the name as
+ * provided by format_name() which uses the format_nodes array as input
+ * "total" is the number of arcs nodes with the same type (ex: cpu)
+ * "index" is the occurrence number of the arc node (ex: cpu number 32)
+ * Fills *kobj with the kobject
+ * Return 0 upon success
+ */
+static int create_sysfs_folder(struct mdesc_handle *hp,
+			       struct mdesc_elem *ep,
+			       const char *name,
+			       struct kobject **kobj,
+			       struct kobject *parent_kobj,
+			       unsigned int index,
+			       unsigned int total)
+{
+	char *formatted;
+	int  err = 0;
+
+	formatted = format_name(hp, ep, name, index, total);
+	if (!formatted)
+		formatted = (char *) name;
+
+	*kobj = kobject_create_and_add(formatted, parent_kobj);
+
+	err = (*kobj = NULL) ? -ENOMEM : 0;
+	if (err)
+		pr_err("mdesc_sysfs: unable to create sysfs entry for \"%s\"\n",
+		       name);
+
+	if (formatted != name)
+		kfree(formatted);
+
+	return err;
+}
+
+/*
+ * Similar to create_sysfs_folder() except that because the node in "ep"
+ * already exist elsewhere in sysfs, a link is created instead.
+ * Return 0 upon success
+ */
+static int create_sysfs_link(struct mdesc_handle *hp,
+			     struct mdesc_elem *ep,
+			     const char *name,
+			     struct kobject *target_kobj,
+			     struct kobject *parent_kobj,
+			     unsigned int index,
+			     unsigned int total)
+{
+	char *formatted;
+	int  err = 0;
+
+	formatted = format_name(hp, ep, name, index, total);
+	if (!formatted)
+		formatted = (char *) name;
+
+	err = sysfs_create_link(parent_kobj, target_kobj, formatted);
+	if (err)
+		pr_err("mdesc_sysfs: unable to create sysfs link for \"%s\"\n",
+		       name);
+
+	if (formatted != name)
+		kfree(formatted);
+
+	return err;
+}
+
+struct mdesc_arcs {
+	struct list_head list;
+	const char *name;
+	unsigned int count;
+};
+
+/*
+ * Take a node in "ep" and build a linked list of mdesc_arcs elements.
+ * Each element contains a name and how many occurrences exists in "ep".
+ * Return 0 upon success
+ */
+static int sysfs_populate_build_arcs_list(struct mdesc_handle *hp,
+					  struct mdesc_elem *ep,
+					  struct mdesc_arcs *arcs_list)
+{
+	struct mdesc_elem *base = node_block(&hp->mdesc);
+	const char *names = name_block(&hp->mdesc);
+
+	for (ep++; ep->tag != MD_NODE_END; ep++) {
+		const char *arc_name;
+		struct mdesc_arcs *p;
+
+		/* We only care of the forward arcs of the DAG */
+		if (ep->tag != MD_PROP_ARC ||
+				strcmp(names + ep->name_offset, "fwd"))
+			continue;
+
+		arc_name = names + (base + ep->d.val)->name_offset;
+		list_for_each_entry(p, &arcs_list->list, list) {
+			if (!strcmp(p->name, arc_name))
+				break;
+		}
+		/* Have we found arc_name in the list? */
+		if (p = arcs_list) {
+			/* no, we add it to the list */
+			p = kzalloc(sizeof(struct mdesc_arcs), GFP_KERNEL);
+			if (p = NULL) {
+				struct list_head *pos, *q;
+
+				/* An error occured: free the whole list */
+				list_for_each_safe(pos, q, &arcs_list->list) {
+					p = list_entry(pos, struct mdesc_arcs,
+							list);
+					list_del(pos);
+					kfree(p);
+				}
+				return -ENOMEM;
+			}
+			p->name = arc_name;
+			/* add tail allows to keep mdesc's order */
+			list_add_tail(&p->list, &arcs_list->list);
+		}
+		/* increment the occurrence for this arc */
+		p->count++;
+	}
+	return 0;
+}
+
+struct sysfs_property {
+	struct kobj_attribute kattr;
+	char *value;
+	unsigned int length;
+};
+
+static bool updating;
+
+static ssize_t mdesc_sysfs_show(struct kobject *object,
+				struct kobj_attribute *attr,
+				char *buf)
+{
+	struct sysfs_property *prop;
+
+	if (updating)
+		return -EAGAIN; /* This version is stale */
+
+	prop = container_of(attr, struct sysfs_property, kattr);
+	if (prop->length <= PAGE_SIZE) {
+		memcpy(buf, prop->value, prop->length);
+		return prop->length;
+	}
+	return sprintf(buf, "%s\n", MDESC_SYSFS_TOO_LARGE);
+}
+
+/*
+ * Append a property to the list that will be later
+ * passed to sysfs_create_files()
+ * "attributes" is a pointer to an array of "struct attribute*"
+ */
+static int add_property(struct sysfs_property *prop,
+			struct attribute ***attributes,
+			int *length,
+			int *size)
+{
+	if (*size <= (*length + 1)) {
+		struct attribute **p;
+
+		*size += 16; /* pre-allocation to relieve the allocator */
+		p = krealloc(*attributes, *size * sizeof(struct attribute *),
+				GFP_KERNEL);
+		if (!p)
+			return -ENOMEM;
+
+		*attributes = p;
+	}
+	(*attributes)[(*length)++] = &prop->kattr.attr;
+	/* the array must be NULL terminated */
+	(*attributes)[*length] = NULL;
+	return 0;
+}
+
+/*
+ * Given an arc node in "ep", loop through its entries and create
+ * a list of attributes suitable for sysfs_create_files()
+ * the entries should be be unique within "ep" but there are versions
+ * where entries are duplicated, so we only add them once to the list
+ */
+static int mdesc_sysfs_add_propeties(struct mdesc_handle *hp,
+				     struct mdesc_elem *ep,
+				     struct kobject *parent_kobj)
+{
+	const char *names = name_block(&hp->mdesc);
+	void *data = data_block(&hp->mdesc);
+	struct attribute **sysfs_attributes = NULL;
+	int sysfs_attributes_length = 0;
+	int sysfs_attributes_size = 0;
+	int err;
+
+	for (ep++; ep->tag != MD_NODE_END; ep++) {
+		struct sysfs_property *prop;
+		char *s = NULL;
+		size_t len = 0;
+		bool valid = false;
+
+		switch (ep->tag) {
+		case MD_PROP_VAL:
+			err = alloc_sprintf(&s, "%lld\n", ep->d.val);
+			if (err)
+				return -ENOMEM;
+			len = strlen(s);
+			valid = true;
+			break;
+		case MD_PROP_STR:
+			s = kstrndup(data + ep->d.data.data_offset,
+				     ep->d.data.data_len, GFP_KERNEL);
+			s = kmalloc(ep->d.data.data_len+1, GFP_KERNEL);
+			if (s = NULL)
+				return -ENOMEM;
+			memcpy(s, data + ep->d.data.data_offset,
+			       ep->d.data.data_len-1);
+			s[ep->d.data.data_len-1] = '\n';
+			s[ep->d.data.data_len] = '\0';
+			len = ep->d.data.data_len;
+			valid = true;
+			break;
+		case MD_PROP_DATA:
+			s = kmalloc(ep->d.data.data_len, GFP_KERNEL);
+			if (s = NULL)
+				return -ENOMEM;
+			memcpy(s, data + ep->d.data.data_offset,
+					ep->d.data.data_len);
+			len = ep->d.data.data_len;
+			valid = true;
+			break;
+		default:
+			break;
+		}
+
+		prop = kmalloc(sizeof(*prop), GFP_KERNEL);
+		if (!prop) {
+			kfree(s);
+			kfree(sysfs_attributes);
+			return -ENOMEM;
+		}
+
+		if (valid) {
+			const char *c_name = names + ep->name_offset;
+			char *name;
+			int i;
+			bool found = false;
+
+			/*
+			 * Check if a property with the same name
+			 * has already been added
+			 */
+			for (i = 0; i < sysfs_attributes_length; i++) {
+				struct sysfs_property *prop;
+
+				prop = container_of(sysfs_attributes[i],
+						    struct sysfs_property,
+						    kattr.attr);
+				if (!strcmp(prop->kattr.attr.name, c_name)) {
+					found = true;
+					break;
+				}
+			}
+			if (found) {
+				pr_info("mdesc_sysfs: duplicate property found\n");
+				continue;
+			}
+
+			name = kstrdup(c_name, GFP_KERNEL);
+			if (!name) {
+				kfree(s);
+				kfree(sysfs_attributes);
+				return -ENOMEM;
+			}
+
+			/* Set the name */
+			prop->kattr.attr.name = name;
+			prop->kattr.attr.mode = S_IRUSR;
+			prop->kattr.show = mdesc_sysfs_show;
+			prop->kattr.store = NULL;
+			prop->value = s;
+			prop->length = len;
+
+			/* Add to the (automatically growing) array */
+			add_property(prop, &sysfs_attributes,
+				     &sysfs_attributes_length,
+				     &sysfs_attributes_size);
+		}
+	}
+
+	if (sysfs_attributes) {
+		int err;
+		const struct attribute **pattr = (const struct attribute **)
+						 sysfs_attributes;
+
+		err = sysfs_create_files(parent_kobj, pattr);
+		if (err)
+			pr_err("mdesc_sysfs: unable to create sysfs properties\n");
+
+		/*
+		 * Free the array of attributes, but not the individual elements
+		 * because each element points to a "struct sysfs_property" that
+		 * mdesc_sysfs_show() uses whenever users read from sysfs
+		 */
+		kfree(sysfs_attributes);
+	}
+
+	return 0;
+}
+
+/*
+ * Function called on the root that recursively add nodes to sysfs
+ * It first looks at the current node in "ep", gathering statistics
+ * on every forward arcs it points to,
+ * then for every arc type it create a sysfs folder or link
+ * Finally it adds the properties (non arcs) to sysfs
+ * Return 0 upon success
+ */
+static int sysfs_populate(struct mdesc_handle *hp,
+			  struct mdesc_elem *ep,
+			  struct kobject *parent_kobj,
+			  struct kobject **all_nodes)
+{
+	struct mdesc_elem *base = node_block(&hp->mdesc);
+	const char *names = name_block(&hp->mdesc);
+	struct mdesc_arcs arcs_list, *p;
+	struct list_head *pos, *q;
+	int err = 0;
+
+	/*
+	 * Check that it's indeed an arc node
+	 * and lose the 1st entry as it's not useful hereafter
+	 */
+	if (ep++->tag != MD_NODE) {
+		pr_err("mdesc_sysfs: Not a valid arc node\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * In a high level language we'd create a dictionary
+	 * for example: {"cpu": 64", "memory": 1, ...}
+	 * In the kernel we use a linked list of structs.
+	 * We end up with: ("cpu", 64) --> ("memory", 1) -->...
+	 */
+	INIT_LIST_HEAD(&arcs_list.list);
+	err = sysfs_populate_build_arcs_list(hp, ep, &arcs_list);
+	if (err)
+		return err;
+
+	/*
+	 * For each arc type, we browse the current arc "ep" and
+	 * add to sysfs. That allows us to keep an index for these
+	 * arcs that don't contain an "id" or "name" field
+	 */
+	list_for_each_entry(p, &arcs_list.list, list) {
+		struct mdesc_elem *elem;
+		unsigned int index = 0;
+
+		for (elem = ep; elem->tag != MD_NODE_END; elem++) {
+			struct kobject *kobj;
+			const char *name;
+
+			/* Need to be a forward arc... */
+			if (elem->tag != MD_PROP_ARC ||
+			    strcmp(names + elem->name_offset, "fwd"))
+				continue;
+
+			/*
+			 * ...whose name matches the element of the list
+			 * that we're currently considering
+			 */
+			name = names + (base + elem->d.val)->name_offset;
+			if (strcmp(p->name, name))
+				continue;
+
+			/* Have we already added this arc to sysfs? */
+			if (all_nodes[elem->d.val]) {
+				/* Yes, we link to it */
+				err = create_sysfs_link(hp, elem, name,
+					all_nodes[elem->d.val], parent_kobj,
+					index, p->count);
+			} else {
+				/* No, we create a folder for it */
+				err = create_sysfs_folder(hp, elem, name,
+					&kobj, parent_kobj, index, p->count);
+				if (err)
+					return -ENOMEM;
+
+				all_nodes[elem->d.val] = kobj;
+
+				/* And we add to sysfs whatever it contains */
+				sysfs_populate(hp, base + elem->d.val,
+					       kobj, all_nodes);
+			}
+
+			/*
+			 * If it's the last entry of its kind, there's
+			 * no point in looping again
+			 */
+			if (++index = p->count)
+				break;
+		}
+	}
+
+	/* Free the linked list */
+	list_for_each_safe(pos, q, &arcs_list.list) {
+		p = list_entry(pos, struct mdesc_arcs, list);
+		list_del(pos);
+		kfree(p);
+	}
+
+	/* Add the properties (non-arc) to sysfs (string, int, binary data) */
+	return mdesc_sysfs_add_propeties(hp, ep, parent_kobj);
+}
+
+static struct kobject *mdesc_kobj;
+
+int mdesc_sysfs_populate(void)
+{
+	struct mdesc_handle *hp;
+	unsigned int num_node;
+	struct kobject **all_nodes, *old_mdesc_kobj;
+	unsigned int major, minor;
+	mode_t mode;
+	int retval = 0;
+
+	hp = mdesc_grab();
+	if (!hp) {
+		pr_err("mdesc_sysfs: hv mdesc not found\n");
+		return -ENODEV;
+	}
+
+	major = hp->mdesc.version >> 16;
+	minor = hp->mdesc.version & 0xffff;
+
+	if (major != 1) {
+		pr_err("mdesc_sysfs: unsupported hv mdesc version: %d.%d\n",
+		       major, minor);
+		mdesc_release(hp);
+		return -EINVAL;
+	}
+
+	pr_info("mdesc_sysfs: machine desc version %d.%d\n", major, minor);
+
+	num_node = hp->mdesc.node_sz / sizeof(struct mdesc_hdr);
+	all_nodes = kcalloc(num_node, sizeof(struct kobject *), GFP_KERNEL);
+	if (!all_nodes) {
+		mdesc_release(hp);
+		return -ENOMEM;
+	}
+
+	updating = true;
+
+	old_mdesc_kobj = mdesc_kobj;
+	mdesc_kobj = kobject_create_and_add(".mdesc.tmp", firmware_kobj);
+	if (!mdesc_kobj) {
+		pr_err("mdesc_sysfs: unable to create sysfs entry\n");
+		kfree(all_nodes);
+		mdesc_release(hp);
+		return -ENOMEM;
+	}
+	mode = mdesc_kobj->sd->mode;
+	/* Remove access to everyone since we're populating
+	 * the tree. Regardless, root has always access! */
+	mdesc_kobj->sd->mode &= ~0777;
+
+	retval = sysfs_populate(hp, node_block(&hp->mdesc),
+				mdesc_kobj, all_nodes);
+
+	mdesc_release(hp);
+	kfree(all_nodes);
+
+	/* Rename existing mdesc to avoid conflicts */
+	if (retval)
+		return retval;
+
+	if (old_mdesc_kobj) {
+		retval = kobject_rename(old_mdesc_kobj, ".mdesc.old");
+		if (retval) {
+			pr_err("mdesc_sysfs: unable to rename /sys/firmware/mdesc\n");
+			kobject_del(mdesc_kobj);
+			kobject_put(mdesc_kobj);
+			updating = false;
+			return retval;
+		}
+	}
+
+	/* Restore original mode and set name */
+	retval = kobject_rename(mdesc_kobj, "mdesc");
+	if (!retval) {
+		mdesc_kobj->sd->mode = mode;
+		if (old_mdesc_kobj) {
+			kobject_del(old_mdesc_kobj);
+			kobject_put(old_mdesc_kobj);
+		}
+	} else {
+		int dummy;
+
+		/* Attempt to restore the old entry (if any) */
+		if (old_mdesc_kobj)
+			dummy = kobject_rename(old_mdesc_kobj, "mdesc");
+		kobject_del(mdesc_kobj);
+		kobject_put(mdesc_kobj);
+	}
+
+	updating = false;
+
+	return retval;
+}
+EXPORT_SYMBOL(mdesc_sysfs_populate);
+
+MODULE_DESCRIPTION("Maps machine description graph to sysfs in /sys/firmware/mdesc");
+MODULE_AUTHOR("Oracle");
+MODULE_LICENSE("GPL");
+
+static int __init mdesc_sysfs_init(void)
+{
+	return mdesc_sysfs_populate();
+}
+
+static void __exit mdesc_sysfs_cleanup(void)
+{
+	if (mdesc_kobj) {
+		kobject_del(mdesc_kobj);
+		kobject_put(mdesc_kobj);
+	}
+}
+
+module_init(mdesc_sysfs_init);
+module_exit(mdesc_sysfs_cleanup);
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (53 preceding siblings ...)
  2017-09-29  9:14 ` Eric Saint-Etienne
@ 2017-12-01 17:15 ` Eric Saint Etienne
  2017-12-01 19:46 ` David Miller
                   ` (21 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Eric Saint Etienne @ 2017-12-01 17:15 UTC (permalink / raw)
  To: sparclinux

Hi Dave,

Do you have any concern with this patch?

Thanks.

Eric

On 29/09/17 10:14, Eric Saint-Etienne wrote:
> To get a snapshot as complete as possible of what the system is composed of,
> this commit adds the ability to browse machine description from sysfs.
>
> This commit eases porting of user-space utilities that exist on other architectures.
>
> Whenever the HV changes machine description content, sysfs will be re-populated.
> This is done almost atomically by swapping the old mdesc sysfs folder with the
> new one. While the tree under the new folder is being created, reading from
> /sys/firmware/mdesc will return EAGAIN. That way userspace programs will not see
> stale content in /sys/firmware/mdesc
>
> Signed-off-by: Eric Saint Etienne <eric.saint.etienne@oracle.com>
> Reviewed-by: David Aldridge <david.j.aldridge@oracle.com>
> ---
>   arch/sparc/Kconfig              |    8 +
>   arch/sparc/kernel/Makefile      |    3 +
>   arch/sparc/kernel/mdesc.c       |    8 +
>   arch/sparc/kernel/mdesc_sysfs.c |  831 +++++++++++++++++++++++++++++++++++++++
>   4 files changed, 850 insertions(+), 0 deletions(-)
>   create mode 100644 arch/sparc/kernel/mdesc_sysfs.c
>
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index a4a6261..4e2b640 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -470,6 +470,14 @@ config UBOOT_ENTRY_ADDR
>   endmenu
>   endif
>   
> +config MDESC_SYSFS
> +	bool "Maps machine description to sysfs"
> +	depends on SPARC64
> +	default y
> +	---help---
> +	  If you say Y here, the directed acyclic graph described in the machine
> +	  description will be expanded and made available in /sys/firmware/mdesc
> +
>   endmenu
>   
>   menu "Bus options (PCI etc.)"
> diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile
> index aac6098..328eb9c 100644
> --- a/arch/sparc/kernel/Makefile
> +++ b/arch/sparc/kernel/Makefile
> @@ -118,3 +118,6 @@ obj-$(CONFIG_SPARC64)	+= $(pc--y)
>   
>   obj-$(CONFIG_UPROBES)	+= uprobes.o
>   obj-$(CONFIG_SPARC64)	+= jump_label.o
> +
> +obj-$(CONFIG_MDESC_SYSFS) += mdesc_sysfs.o
> +
> diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel/mdesc.c
> index fa466ce..75db846 100644
> --- a/arch/sparc/kernel/mdesc.c
> +++ b/arch/sparc/kernel/mdesc.c
> @@ -87,6 +87,10 @@ struct md_node_ops {
>   	mdesc_node_match_f	node_match;
>   };
>   
> +#ifdef MDESC_SYSFS
> +int mdesc_sysfs_populate(void);
> +#endif
> +
>   static int get_vdev_port_node_info(struct mdesc_handle *md, u64 node,
>   				   union md_node_info *node_info);
>   static void rel_vdev_port_node_info(union md_node_info *node_info);
> @@ -523,6 +527,10 @@ void mdesc_update(void)
>   	cur_mdesc = hp;
>   	spin_unlock_irqrestore(&mdesc_lock, flags);
>   
> +#ifdef MDESC_SYSFS
> +	mdesc_sysfs_populate();
> +#endif
> +
>   	mdesc_notify_clients(orig_hp, hp);
>   
>   	spin_lock_irqsave(&mdesc_lock, flags);
> diff --git a/arch/sparc/kernel/mdesc_sysfs.c b/arch/sparc/kernel/mdesc_sysfs.c
> new file mode 100644
> index 0000000..f2e048c
> --- /dev/null
> +++ b/arch/sparc/kernel/mdesc_sysfs.c
> @@ -0,0 +1,831 @@
> +/*
> + * mdesc_sysfs.c - Maps machine description DAG to sysfs
> + *
> + * Copyright (c) 2017 Oracle and/or its affiliates. All rights reserved.
> + * Author: Eric Saint-Etienne
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; see the file COPYING.  If not, write to
> + * the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139,
> + * USA.
> + *
> + */
> +
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <asm/mdesc.h>
> +
> +#define MDESC_SYSFS_TOO_LARGE "Error: Not enough space to output the data, retrieve it from /dev/mdesc instead."
> +
> +/*
> + * Machine Description is described in slides 37-39 here:
> + * http://www.oracle.com/technetwork/systems/opensparc/2008-oct-opensparc-slide-cast-09-mw-1539018.html
> + *
> + * It is composed of three main sections decribed by the following mdesc header.
> + * Since these blocks are contiguous, describing their size is sufficient to
> + * precisely locate them within the mdesc blob.
> + *
> + * - The NODE block contains the nodes of the directed acyclic graph (DAG)
> + * - The NAME block contains names of properties referred to by the DAG nodes
> + * - The DATA block contains values for the properties: strings and binary data
> + *
> + * A public specification of mdesc is available online at:
> + * https://kenai.com/downloads/hypervisor/hypervisor-api-3.0draft7.pdf
> + */
> +struct mdesc_hdr {
> +	u32	version; /* Transport version */
> +	u32	node_sz; /* node block size */
> +	u32	name_sz; /* name block size */
> +	u32	data_sz; /* data block size */
> +} __aligned(16)__;
> +
> +struct mdesc_elem {
> +	u8	tag;
> +#define MD_LIST_END	0x00
> +#define MD_NODE		0x4e
> +#define MD_NODE_END	0x45
> +#define MD_NOOP		0x20
> +#define MD_PROP_ARC	0x61
> +#define MD_PROP_VAL	0x76
> +#define MD_PROP_STR	0x73
> +#define MD_PROP_DATA	0x64
> +	u8	name_len;
> +	u16	resv;
> +	u32	name_offset;
> +	union {
> +		struct {
> +			u32	data_len;
> +			u32	data_offset;
> +		} data;
> +		u64	val;
> +	} d;
> +};
> +
> +struct mdesc_mem_ops {
> +	struct mdesc_handle *(*alloc)(unsigned int mdesc_size);
> +	void (*free)(struct mdesc_handle *handle);
> +};
> +
> +struct mdesc_handle {
> +	struct list_head     list;
> +	struct mdesc_mem_ops *mops;
> +	void                 *self_base;
> +	atomic_t             refcnt;
> +	unsigned int         handle_size;
> +	struct mdesc_hdr     mdesc;
> +};
> +
> +/*
> + * The following 3 functions return a pointer of the right type to the
> + * 3 main mdesc blocks
> + */
> +
> +static inline struct mdesc_elem *node_block(struct mdesc_hdr *mdesc)
> +{
> +	return (struct mdesc_elem *) (mdesc + 1);
> +}
> +
> +static inline void *name_block(struct mdesc_hdr *mdesc)
> +{
> +	return ((void *) node_block(mdesc)) + mdesc->node_sz;
> +}
> +
> +static inline void *data_block(struct mdesc_hdr *mdesc)
> +{
> +	return ((void *) name_block(mdesc)) + mdesc->name_sz;
> +}
> +
> +/*
> + * Dynamically allocates the right amount of characters to format according
> + * to the printf-like format specified in "fmt".
> + * "*buf" is allocated and filled.
> + *
> + * Return 0 upon success
> + */
> +static int alloc_sprintf(char **buf, const char *fmt, ...)
> +{
> +	va_list args;
> +	size_t len, actual;
> +
> +	va_start(args, fmt);
> +	len = vsnprintf(NULL, 0, fmt, args);
> +	va_end(args);
> +
> +	*buf = kmalloc(len+1, GFP_KERNEL);
> +	if (!*buf)
> +		return -ENOMEM;
> +
> +	va_start(args, fmt);
> +	actual = vscnprintf(*buf, len + 1, fmt, args);
> +	va_end(args);
> +
> +	if (actual != len) {
> +		kfree(*buf);
> +		*buf = NULL;
> +		return -ENOMEM;
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * Flags used with the following formatting functions that modify the way
> + * node names are formatted
> + */
> +#define FORMAT_APPEND    0x01
> +#define FORMAT_USE_INDEX 0x02
> +
> +/*
> + * Take an arc node in "ep" and format it using the "id" field as to avoid
> + * collision when adding to sysfs.
> + * Ex: multiple "cpu" nodes in the same folder will be named: "0", "1"...
> + *
> + * When FORMAT_APPEND is used, the names will become: "cpu0", "cpu1"...
> + * The formatted string is found in *formatted, to be freed by the caller
> + *
> + * Return 0 upon success
> + */
> +static int format_using_id(struct mdesc_handle *hp,
> +			   struct mdesc_elem *ep,
> +			   char const *name,
> +			   char **formatted,
> +			   unsigned int flags,
> +			   unsigned int index,
> +			   unsigned int total)
> +{
> +	const u64 *prop_id = mdesc_get_property(hp, ep->d.val, "id", NULL);
> +
> +	if (!prop_id) {
> +		pr_err("mdesc %s doesn't have a property \"id\"\n", name);
> +		return -ENOENT;
> +	}
> +
> +	if (flags & FORMAT_APPEND)
> +		return alloc_sprintf(formatted, "%s%lld", name, *prop_id);
> +
> +	return alloc_sprintf(formatted, "%lld", *prop_id);
> +}
> +
> +/*
> + * Take an arc node in "ep" and format it using the "name" field as to avoid
> + * collision when adding to sysfs.
> + * Ex: multiple "virtual-device" nodes in the same folder will be named:
> + * "disk", "network"...
> + *
> + * When FORMAT_APPEND is used: "virtual-device-disk", virtual-device-network"...
> + *
> + * Because the "name" field is not guaranteed to be unique, one can use the
> + * flag FORMAT_USE_INDEX: "virtual-device0-disk", virtual-device1-network"...
> + * In this case "index" is used.
> + *
> + * The formatted string is found in *formatted, to be freed by the caller
> + *
> + * Return 0 upon success
> + */
> +static int format_using_name(struct mdesc_handle *hp,
> +			     struct mdesc_elem *ep,
> +			     const char *name,
> +			     char **formatted,
> +			     unsigned int flags,
> +			     unsigned int index,
> +			     unsigned int total)
> +{
> +	const char *prop_name = mdesc_get_property(hp, ep->d.val, "name", NULL);
> +
> +	if (!prop_name) {
> +		pr_err("mdesc %s doesn't have a property \"name\"\n", name);
> +		return -ENOENT;
> +	}
> +
> +	if (flags & FORMAT_APPEND) {
> +		if (flags & FORMAT_USE_INDEX)
> +			return alloc_sprintf(formatted, "%s%d_%s",
> +					     name, index, prop_name);
> +		else
> +			return alloc_sprintf(formatted, "%s_%s",
> +					     name, prop_name);
> +	}
> +
> +	if (flags & FORMAT_USE_INDEX)
> +		return alloc_sprintf(formatted, "%s%d", prop_name, index);
> +	else
> +		return alloc_sprintf(formatted, "%s", prop_name);
> +}
> +
> +/*
> + * Default formatting used in format_name() for arcs nodes.
> + * Called when we find multiple arcs with the same name for which no
> + * formatting is specified in format_nodes array.
> + * This default formatting guarantees uniqueness because it is using the node
> + * index in the mdesc nodes array
> + */
> +static char *format_name_fallback(struct mdesc_handle *hp,
> +				  struct mdesc_elem *ep,
> +				  const char *name,
> +				  unsigned int    index,
> +				  unsigned int    total)
> +{
> +	char *formatted = NULL;
> +	int err;
> +
> +	err = alloc_sprintf(&formatted, "%s_0x%x", name, ep->d.val);
> +	return err ? NULL : formatted;
> +}
> +
> +struct format_node {
> +	char	*name;
> +	int	(*format)(struct mdesc_handle*, struct mdesc_elem*, const char*,
> +			char**, unsigned int, unsigned int, unsigned int);
> +	unsigned int flags;
> +};
> +
> +struct format_node format_nodes[] = {
> +#define FORMAT_APPEND_USE_INDEX (FORMAT_APPEND | FORMAT_USE_INDEX)
> +	{ "virtual-device",       format_using_name, FORMAT_APPEND_USE_INDEX },
> +	{ "domain-services-port", format_using_id,   FORMAT_APPEND },
> +	{ "virtual-device-port",  format_using_id,   FORMAT_APPEND },
> +	{ "channel-endpoint",     format_using_id,   FORMAT_APPEND },
> +	{ "cpu",                  format_using_id,   FORMAT_APPEND },
> +	{ NULL, NULL, 0 }
> +};
> +
> +/*
> + * Format the name of an arc node according to the table "format_nodes".
> + * If no entry is found for the arc node in "ep", it falls back to using
> + * format_name_fallback()
> + * Returns the formatted string, to be freed by the caller
> + */
> +static char *format_name(struct mdesc_handle *hp,
> +			 struct mdesc_elem *ep,
> +			 const char *name,
> +			 int    index,
> +			 int    total)
> +{
> +	struct format_node *fn;
> +	char   *formatted = NULL;
> +	bool   found = false;
> +	int    err = 0;
> +
> +	for (fn = format_nodes; fn->name; fn++) {
> +		if (strcmp(fn->name, name))
> +			continue;
> +		err = fn->format(hp, ep, name, &formatted,
> +				 fn->flags, index, total);
> +		found = true;
> +		break;
> +	}
> +
> +	if (!found && (total != 1)) {
> +		/*
> +		 * there's no handler for this node and we've got more
> +		 * than one so we format it by appending the index
> +		 * (by order of appearance)
> +		 */
> +		err = alloc_sprintf(&formatted, "%s%lld", name, index);
> +	}
> +
> +	if (err)
> +		return format_name_fallback(hp, ep, name, index, total);
> +
> +	return formatted;
> +}
> +
> +/*
> + * Takes an arc node in "ep" and create a folder in sysfs with the name as
> + * provided by format_name() which uses the format_nodes array as input
> + * "total" is the number of arcs nodes with the same type (ex: cpu)
> + * "index" is the occurrence number of the arc node (ex: cpu number 32)
> + * Fills *kobj with the kobject
> + * Return 0 upon success
> + */
> +static int create_sysfs_folder(struct mdesc_handle *hp,
> +			       struct mdesc_elem *ep,
> +			       const char *name,
> +			       struct kobject **kobj,
> +			       struct kobject *parent_kobj,
> +			       unsigned int index,
> +			       unsigned int total)
> +{
> +	char *formatted;
> +	int  err = 0;
> +
> +	formatted = format_name(hp, ep, name, index, total);
> +	if (!formatted)
> +		formatted = (char *) name;
> +
> +	*kobj = kobject_create_and_add(formatted, parent_kobj);
> +
> +	err = (*kobj = NULL) ? -ENOMEM : 0;
> +	if (err)
> +		pr_err("mdesc_sysfs: unable to create sysfs entry for \"%s\"\n",
> +		       name);
> +
> +	if (formatted != name)
> +		kfree(formatted);
> +
> +	return err;
> +}
> +
> +/*
> + * Similar to create_sysfs_folder() except that because the node in "ep"
> + * already exist elsewhere in sysfs, a link is created instead.
> + * Return 0 upon success
> + */
> +static int create_sysfs_link(struct mdesc_handle *hp,
> +			     struct mdesc_elem *ep,
> +			     const char *name,
> +			     struct kobject *target_kobj,
> +			     struct kobject *parent_kobj,
> +			     unsigned int index,
> +			     unsigned int total)
> +{
> +	char *formatted;
> +	int  err = 0;
> +
> +	formatted = format_name(hp, ep, name, index, total);
> +	if (!formatted)
> +		formatted = (char *) name;
> +
> +	err = sysfs_create_link(parent_kobj, target_kobj, formatted);
> +	if (err)
> +		pr_err("mdesc_sysfs: unable to create sysfs link for \"%s\"\n",
> +		       name);
> +
> +	if (formatted != name)
> +		kfree(formatted);
> +
> +	return err;
> +}
> +
> +struct mdesc_arcs {
> +	struct list_head list;
> +	const char *name;
> +	unsigned int count;
> +};
> +
> +/*
> + * Take a node in "ep" and build a linked list of mdesc_arcs elements.
> + * Each element contains a name and how many occurrences exists in "ep".
> + * Return 0 upon success
> + */
> +static int sysfs_populate_build_arcs_list(struct mdesc_handle *hp,
> +					  struct mdesc_elem *ep,
> +					  struct mdesc_arcs *arcs_list)
> +{
> +	struct mdesc_elem *base = node_block(&hp->mdesc);
> +	const char *names = name_block(&hp->mdesc);
> +
> +	for (ep++; ep->tag != MD_NODE_END; ep++) {
> +		const char *arc_name;
> +		struct mdesc_arcs *p;
> +
> +		/* We only care of the forward arcs of the DAG */
> +		if (ep->tag != MD_PROP_ARC ||
> +				strcmp(names + ep->name_offset, "fwd"))
> +			continue;
> +
> +		arc_name = names + (base + ep->d.val)->name_offset;
> +		list_for_each_entry(p, &arcs_list->list, list) {
> +			if (!strcmp(p->name, arc_name))
> +				break;
> +		}
> +		/* Have we found arc_name in the list? */
> +		if (p = arcs_list) {
> +			/* no, we add it to the list */
> +			p = kzalloc(sizeof(struct mdesc_arcs), GFP_KERNEL);
> +			if (p = NULL) {
> +				struct list_head *pos, *q;
> +
> +				/* An error occured: free the whole list */
> +				list_for_each_safe(pos, q, &arcs_list->list) {
> +					p = list_entry(pos, struct mdesc_arcs,
> +							list);
> +					list_del(pos);
> +					kfree(p);
> +				}
> +				return -ENOMEM;
> +			}
> +			p->name = arc_name;
> +			/* add tail allows to keep mdesc's order */
> +			list_add_tail(&p->list, &arcs_list->list);
> +		}
> +		/* increment the occurrence for this arc */
> +		p->count++;
> +	}
> +	return 0;
> +}
> +
> +struct sysfs_property {
> +	struct kobj_attribute kattr;
> +	char *value;
> +	unsigned int length;
> +};
> +
> +static bool updating;
> +
> +static ssize_t mdesc_sysfs_show(struct kobject *object,
> +				struct kobj_attribute *attr,
> +				char *buf)
> +{
> +	struct sysfs_property *prop;
> +
> +	if (updating)
> +		return -EAGAIN; /* This version is stale */
> +
> +	prop = container_of(attr, struct sysfs_property, kattr);
> +	if (prop->length <= PAGE_SIZE) {
> +		memcpy(buf, prop->value, prop->length);
> +		return prop->length;
> +	}
> +	return sprintf(buf, "%s\n", MDESC_SYSFS_TOO_LARGE);
> +}
> +
> +/*
> + * Append a property to the list that will be later
> + * passed to sysfs_create_files()
> + * "attributes" is a pointer to an array of "struct attribute*"
> + */
> +static int add_property(struct sysfs_property *prop,
> +			struct attribute ***attributes,
> +			int *length,
> +			int *size)
> +{
> +	if (*size <= (*length + 1)) {
> +		struct attribute **p;
> +
> +		*size += 16; /* pre-allocation to relieve the allocator */
> +		p = krealloc(*attributes, *size * sizeof(struct attribute *),
> +				GFP_KERNEL);
> +		if (!p)
> +			return -ENOMEM;
> +
> +		*attributes = p;
> +	}
> +	(*attributes)[(*length)++] = &prop->kattr.attr;
> +	/* the array must be NULL terminated */
> +	(*attributes)[*length] = NULL;
> +	return 0;
> +}
> +
> +/*
> + * Given an arc node in "ep", loop through its entries and create
> + * a list of attributes suitable for sysfs_create_files()
> + * the entries should be be unique within "ep" but there are versions
> + * where entries are duplicated, so we only add them once to the list
> + */
> +static int mdesc_sysfs_add_propeties(struct mdesc_handle *hp,
> +				     struct mdesc_elem *ep,
> +				     struct kobject *parent_kobj)
> +{
> +	const char *names = name_block(&hp->mdesc);
> +	void *data = data_block(&hp->mdesc);
> +	struct attribute **sysfs_attributes = NULL;
> +	int sysfs_attributes_length = 0;
> +	int sysfs_attributes_size = 0;
> +	int err;
> +
> +	for (ep++; ep->tag != MD_NODE_END; ep++) {
> +		struct sysfs_property *prop;
> +		char *s = NULL;
> +		size_t len = 0;
> +		bool valid = false;
> +
> +		switch (ep->tag) {
> +		case MD_PROP_VAL:
> +			err = alloc_sprintf(&s, "%lld\n", ep->d.val);
> +			if (err)
> +				return -ENOMEM;
> +			len = strlen(s);
> +			valid = true;
> +			break;
> +		case MD_PROP_STR:
> +			s = kstrndup(data + ep->d.data.data_offset,
> +				     ep->d.data.data_len, GFP_KERNEL);
> +			s = kmalloc(ep->d.data.data_len+1, GFP_KERNEL);
> +			if (s = NULL)
> +				return -ENOMEM;
> +			memcpy(s, data + ep->d.data.data_offset,
> +			       ep->d.data.data_len-1);
> +			s[ep->d.data.data_len-1] = '\n';
> +			s[ep->d.data.data_len] = '\0';
> +			len = ep->d.data.data_len;
> +			valid = true;
> +			break;
> +		case MD_PROP_DATA:
> +			s = kmalloc(ep->d.data.data_len, GFP_KERNEL);
> +			if (s = NULL)
> +				return -ENOMEM;
> +			memcpy(s, data + ep->d.data.data_offset,
> +					ep->d.data.data_len);
> +			len = ep->d.data.data_len;
> +			valid = true;
> +			break;
> +		default:
> +			break;
> +		}
> +
> +		prop = kmalloc(sizeof(*prop), GFP_KERNEL);
> +		if (!prop) {
> +			kfree(s);
> +			kfree(sysfs_attributes);
> +			return -ENOMEM;
> +		}
> +
> +		if (valid) {
> +			const char *c_name = names + ep->name_offset;
> +			char *name;
> +			int i;
> +			bool found = false;
> +
> +			/*
> +			 * Check if a property with the same name
> +			 * has already been added
> +			 */
> +			for (i = 0; i < sysfs_attributes_length; i++) {
> +				struct sysfs_property *prop;
> +
> +				prop = container_of(sysfs_attributes[i],
> +						    struct sysfs_property,
> +						    kattr.attr);
> +				if (!strcmp(prop->kattr.attr.name, c_name)) {
> +					found = true;
> +					break;
> +				}
> +			}
> +			if (found) {
> +				pr_info("mdesc_sysfs: duplicate property found\n");
> +				continue;
> +			}
> +
> +			name = kstrdup(c_name, GFP_KERNEL);
> +			if (!name) {
> +				kfree(s);
> +				kfree(sysfs_attributes);
> +				return -ENOMEM;
> +			}
> +
> +			/* Set the name */
> +			prop->kattr.attr.name = name;
> +			prop->kattr.attr.mode = S_IRUSR;
> +			prop->kattr.show = mdesc_sysfs_show;
> +			prop->kattr.store = NULL;
> +			prop->value = s;
> +			prop->length = len;
> +
> +			/* Add to the (automatically growing) array */
> +			add_property(prop, &sysfs_attributes,
> +				     &sysfs_attributes_length,
> +				     &sysfs_attributes_size);
> +		}
> +	}
> +
> +	if (sysfs_attributes) {
> +		int err;
> +		const struct attribute **pattr = (const struct attribute **)
> +						 sysfs_attributes;
> +
> +		err = sysfs_create_files(parent_kobj, pattr);
> +		if (err)
> +			pr_err("mdesc_sysfs: unable to create sysfs properties\n");
> +
> +		/*
> +		 * Free the array of attributes, but not the individual elements
> +		 * because each element points to a "struct sysfs_property" that
> +		 * mdesc_sysfs_show() uses whenever users read from sysfs
> +		 */
> +		kfree(sysfs_attributes);
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * Function called on the root that recursively add nodes to sysfs
> + * It first looks at the current node in "ep", gathering statistics
> + * on every forward arcs it points to,
> + * then for every arc type it create a sysfs folder or link
> + * Finally it adds the properties (non arcs) to sysfs
> + * Return 0 upon success
> + */
> +static int sysfs_populate(struct mdesc_handle *hp,
> +			  struct mdesc_elem *ep,
> +			  struct kobject *parent_kobj,
> +			  struct kobject **all_nodes)
> +{
> +	struct mdesc_elem *base = node_block(&hp->mdesc);
> +	const char *names = name_block(&hp->mdesc);
> +	struct mdesc_arcs arcs_list, *p;
> +	struct list_head *pos, *q;
> +	int err = 0;
> +
> +	/*
> +	 * Check that it's indeed an arc node
> +	 * and lose the 1st entry as it's not useful hereafter
> +	 */
> +	if (ep++->tag != MD_NODE) {
> +		pr_err("mdesc_sysfs: Not a valid arc node\n");
> +		return -EINVAL;
> +	}
> +
> +	/*
> +	 * In a high level language we'd create a dictionary
> +	 * for example: {"cpu": 64", "memory": 1, ...}
> +	 * In the kernel we use a linked list of structs.
> +	 * We end up with: ("cpu", 64) --> ("memory", 1) -->...
> +	 */
> +	INIT_LIST_HEAD(&arcs_list.list);
> +	err = sysfs_populate_build_arcs_list(hp, ep, &arcs_list);
> +	if (err)
> +		return err;
> +
> +	/*
> +	 * For each arc type, we browse the current arc "ep" and
> +	 * add to sysfs. That allows us to keep an index for these
> +	 * arcs that don't contain an "id" or "name" field
> +	 */
> +	list_for_each_entry(p, &arcs_list.list, list) {
> +		struct mdesc_elem *elem;
> +		unsigned int index = 0;
> +
> +		for (elem = ep; elem->tag != MD_NODE_END; elem++) {
> +			struct kobject *kobj;
> +			const char *name;
> +
> +			/* Need to be a forward arc... */
> +			if (elem->tag != MD_PROP_ARC ||
> +			    strcmp(names + elem->name_offset, "fwd"))
> +				continue;
> +
> +			/*
> +			 * ...whose name matches the element of the list
> +			 * that we're currently considering
> +			 */
> +			name = names + (base + elem->d.val)->name_offset;
> +			if (strcmp(p->name, name))
> +				continue;
> +
> +			/* Have we already added this arc to sysfs? */
> +			if (all_nodes[elem->d.val]) {
> +				/* Yes, we link to it */
> +				err = create_sysfs_link(hp, elem, name,
> +					all_nodes[elem->d.val], parent_kobj,
> +					index, p->count);
> +			} else {
> +				/* No, we create a folder for it */
> +				err = create_sysfs_folder(hp, elem, name,
> +					&kobj, parent_kobj, index, p->count);
> +				if (err)
> +					return -ENOMEM;
> +
> +				all_nodes[elem->d.val] = kobj;
> +
> +				/* And we add to sysfs whatever it contains */
> +				sysfs_populate(hp, base + elem->d.val,
> +					       kobj, all_nodes);
> +			}
> +
> +			/*
> +			 * If it's the last entry of its kind, there's
> +			 * no point in looping again
> +			 */
> +			if (++index = p->count)
> +				break;
> +		}
> +	}
> +
> +	/* Free the linked list */
> +	list_for_each_safe(pos, q, &arcs_list.list) {
> +		p = list_entry(pos, struct mdesc_arcs, list);
> +		list_del(pos);
> +		kfree(p);
> +	}
> +
> +	/* Add the properties (non-arc) to sysfs (string, int, binary data) */
> +	return mdesc_sysfs_add_propeties(hp, ep, parent_kobj);
> +}
> +
> +static struct kobject *mdesc_kobj;
> +
> +int mdesc_sysfs_populate(void)
> +{
> +	struct mdesc_handle *hp;
> +	unsigned int num_node;
> +	struct kobject **all_nodes, *old_mdesc_kobj;
> +	unsigned int major, minor;
> +	mode_t mode;
> +	int retval = 0;
> +
> +	hp = mdesc_grab();
> +	if (!hp) {
> +		pr_err("mdesc_sysfs: hv mdesc not found\n");
> +		return -ENODEV;
> +	}
> +
> +	major = hp->mdesc.version >> 16;
> +	minor = hp->mdesc.version & 0xffff;
> +
> +	if (major != 1) {
> +		pr_err("mdesc_sysfs: unsupported hv mdesc version: %d.%d\n",
> +		       major, minor);
> +		mdesc_release(hp);
> +		return -EINVAL;
> +	}
> +
> +	pr_info("mdesc_sysfs: machine desc version %d.%d\n", major, minor);
> +
> +	num_node = hp->mdesc.node_sz / sizeof(struct mdesc_hdr);
> +	all_nodes = kcalloc(num_node, sizeof(struct kobject *), GFP_KERNEL);
> +	if (!all_nodes) {
> +		mdesc_release(hp);
> +		return -ENOMEM;
> +	}
> +
> +	updating = true;
> +
> +	old_mdesc_kobj = mdesc_kobj;
> +	mdesc_kobj = kobject_create_and_add(".mdesc.tmp", firmware_kobj);
> +	if (!mdesc_kobj) {
> +		pr_err("mdesc_sysfs: unable to create sysfs entry\n");
> +		kfree(all_nodes);
> +		mdesc_release(hp);
> +		return -ENOMEM;
> +	}
> +	mode = mdesc_kobj->sd->mode;
> +	/* Remove access to everyone since we're populating
> +	 * the tree. Regardless, root has always access! */
> +	mdesc_kobj->sd->mode &= ~0777;
> +
> +	retval = sysfs_populate(hp, node_block(&hp->mdesc),
> +				mdesc_kobj, all_nodes);
> +
> +	mdesc_release(hp);
> +	kfree(all_nodes);
> +
> +	/* Rename existing mdesc to avoid conflicts */
> +	if (retval)
> +		return retval;
> +
> +	if (old_mdesc_kobj) {
> +		retval = kobject_rename(old_mdesc_kobj, ".mdesc.old");
> +		if (retval) {
> +			pr_err("mdesc_sysfs: unable to rename /sys/firmware/mdesc\n");
> +			kobject_del(mdesc_kobj);
> +			kobject_put(mdesc_kobj);
> +			updating = false;
> +			return retval;
> +		}
> +	}
> +
> +	/* Restore original mode and set name */
> +	retval = kobject_rename(mdesc_kobj, "mdesc");
> +	if (!retval) {
> +		mdesc_kobj->sd->mode = mode;
> +		if (old_mdesc_kobj) {
> +			kobject_del(old_mdesc_kobj);
> +			kobject_put(old_mdesc_kobj);
> +		}
> +	} else {
> +		int dummy;
> +
> +		/* Attempt to restore the old entry (if any) */
> +		if (old_mdesc_kobj)
> +			dummy = kobject_rename(old_mdesc_kobj, "mdesc");
> +		kobject_del(mdesc_kobj);
> +		kobject_put(mdesc_kobj);
> +	}
> +
> +	updating = false;
> +
> +	return retval;
> +}
> +EXPORT_SYMBOL(mdesc_sysfs_populate);
> +
> +MODULE_DESCRIPTION("Maps machine description graph to sysfs in /sys/firmware/mdesc");
> +MODULE_AUTHOR("Oracle");
> +MODULE_LICENSE("GPL");
> +
> +static int __init mdesc_sysfs_init(void)
> +{
> +	return mdesc_sysfs_populate();
> +}
> +
> +static void __exit mdesc_sysfs_cleanup(void)
> +{
> +	if (mdesc_kobj) {
> +		kobject_del(mdesc_kobj);
> +		kobject_put(mdesc_kobj);
> +	}
> +}
> +
> +module_init(mdesc_sysfs_init);
> +module_exit(mdesc_sysfs_cleanup);


^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (54 preceding siblings ...)
  2017-12-01 17:15 ` Eric Saint Etienne
@ 2017-12-01 19:46 ` David Miller
  2017-12-01 20:37 ` Eric Saint Etienne
                   ` (20 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-12-01 19:46 UTC (permalink / raw)
  To: sparclinux

From: Eric Saint Etienne <eric.saint.etienne@oracle.com>
Date: Fri, 1 Dec 2017 17:15:13 +0000

> Do you have any concern with this patch?

I'm just wondering if the blacklist of sensitive nodes is complete and
also futureproof.

That's my first concern.

Also the hypervisor specification URL is completely non-functional,
the kenai.com stuff went down years ago.

It's pretty rediculous for me to include code written to a
specification nobody can access and check against the implementation.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (55 preceding siblings ...)
  2017-12-01 19:46 ` David Miller
@ 2017-12-01 20:37 ` Eric Saint Etienne
  2017-12-01 21:28 ` David Miller
                   ` (19 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Eric Saint Etienne @ 2017-12-01 20:37 UTC (permalink / raw)
  To: sparclinux

Hi Dave,

Can you please provide me with an example of an actual mdesc entry that 
needs sanitization? I believe you are thinking of passwords and crypto 
keys but I couldn't find any such entry on any machine I have access to.

It makes sense for this mdesc sysfs module to use the same level of 
sanitization that has been used for so many years for /dev/mdesc without 
any problem.

Regarding the machine description format specification url, what 
specification document did you use or share with the community when you 
initially wrote and upstreamed mdesc.c? Certainly the same document 
could be used for this module as the format hasn't changed since then.

Thank you.

Kind Regards,

-eric


On 01/12/17 19:46, David Miller wrote:
> From: Eric Saint Etienne <eric.saint.etienne@oracle.com>
> Date: Fri, 1 Dec 2017 17:15:13 +0000
>
>> Do you have any concern with this patch?
> I'm just wondering if the blacklist of sensitive nodes is complete and
> also futureproof.
>
> That's my first concern.
>
> Also the hypervisor specification URL is completely non-functional,
> the kenai.com stuff went down years ago.
>
> It's pretty rediculous for me to include code written to a
> specification nobody can access and check against the implementation.


^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (56 preceding siblings ...)
  2017-12-01 20:37 ` Eric Saint Etienne
@ 2017-12-01 21:28 ` David Miller
  2017-12-07 16:40 ` Eric Saint Etienne
                   ` (18 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-12-01 21:28 UTC (permalink / raw)
  To: sparclinux

From: Eric Saint Etienne <eric.saint.etienne@oracle.com>
Date: Fri, 1 Dec 2017 20:37:15 +0000

> Regarding the machine description format specification url, what
> specification document did you use or share with the community when
> you initially wrote and upstreamed mdesc.c? Certainly the same
> document could be used for this module as the format hasn't changed
> since then.

kenai.com was up and running at the time I was doing this code.

I also had documents under NDA (which allowed me to publish the work I
did upstream) at the time as well.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (57 preceding siblings ...)
  2017-12-01 21:28 ` David Miller
@ 2017-12-07 16:40 ` Eric Saint Etienne
  2017-12-07 18:05 ` David Miller
                   ` (17 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Eric Saint Etienne @ 2017-12-07 16:40 UTC (permalink / raw)
  To: sparclinux

 > Can you please provide me with an example of an actual mdesc
 > entry that needs sanitization? I believe you are thinking of
 > passwords and crypto keys but I couldn't find any such entry
 > on any machine I have access to.

Dave, I still have to read from you on this.


^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (58 preceding siblings ...)
  2017-12-07 16:40 ` Eric Saint Etienne
@ 2017-12-07 18:05 ` David Miller
  2017-12-08  8:17 ` Alexandre Chartre
                   ` (16 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-12-07 18:05 UTC (permalink / raw)
  To: sparclinux

From: Eric Saint Etienne <eric.saint.etienne@oracle.com>
Date: Thu, 7 Dec 2017 16:40:14 +0000

>> Can you please provide me with an example of an actual mdesc
>> entry that needs sanitization? I believe you are thinking of
>> passwords and crypto keys but I couldn't find any such entry
>> on any machine I have access to.
> 
> Dave, I still have to read from you on this.

I don't know, but based upon private communication we received from
Greg Onufer some might exist.

Please do a detailed audit of the mdesc properties that might contain
passwords or other sensitive issues, and please provide the results
of your audit on the list here.

Thank you.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (59 preceding siblings ...)
  2017-12-07 18:05 ` David Miller
@ 2017-12-08  8:17 ` Alexandre Chartre
  2017-12-14 11:01 ` Eric Saint Etienne
                   ` (15 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Alexandre Chartre @ 2017-12-08  8:17 UTC (permalink / raw)
  To: sparclinux


On 12/07/2017 07:05 PM, David Miller wrote:
> From: Eric Saint Etienne <eric.saint.etienne@oracle.com>
> Date: Thu, 7 Dec 2017 16:40:14 +0000
>
>>> Can you please provide me with an example of an actual mdesc
>>> entry that needs sanitization? I believe you are thinking of
>>> passwords and crypto keys but I couldn't find any such entry
>>> on any machine I have access to.
>>
>> Dave, I still have to read from you on this.
>
> I don't know, but based upon private communication we received from
> Greg Onufer some might exist.
>
> Please do a detailed audit of the mdesc properties that might contain
> passwords or other sensitive issues, and please provide the results
> of your audit on the list here.
>

FYI, on Solaris, when dumping /dev/mdesc, Solaris filters out the "security-password"
property from the "variables" node, and the "keystore" node.

- "security-password" holds the OBP password if it is set
- "keystore" holds security keys.

alex.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (60 preceding siblings ...)
  2017-12-08  8:17 ` Alexandre Chartre
@ 2017-12-14 11:01 ` Eric Saint Etienne
  2017-12-14 13:44 ` David Miller
                   ` (14 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Eric Saint Etienne @ 2017-12-14 11:01 UTC (permalink / raw)
  To: sparclinux

>>> Can you please provide me with an example of an actual mdesc
>>> entry that needs sanitization? I believe you are thinking of
>>> passwords and crypto keys but I couldn't find any such entry
>>> on any machine I have access to.
>> Dave, I still have to read from you on this.
> I don't know, but based upon private communication we received from
> Greg Onufer some might exist.
>
> Please do a detailed audit of the mdesc properties that might contain
> passwords or other sensitive issues, and please provide the results
> of your audit on the list here.
Alexandre Chartres did part of that audit for us: he pointed out 2 
sensitive mdesc keys that contain passwords and cryptographic keys.

I can't spend much more time on this patch. It's already out there in 
the mailing list archive for whoever wants to use it.

That said this sanitization task should be on top of your sparc todo 
list IMHO because the existing /dev/mdesc driver doesn't filter anything 
as of today, so it leaks critical/sensitive data to the OS.

All the best with fixing /dev/mdesc.

-eric

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (61 preceding siblings ...)
  2017-12-14 11:01 ` Eric Saint Etienne
@ 2017-12-14 13:44 ` David Miller
  2017-12-14 14:59 ` Eric Saint Etienne
                   ` (13 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-12-14 13:44 UTC (permalink / raw)
  To: sparclinux

From: Eric Saint Etienne <eric.saint.etienne@oracle.com>
Date: Thu, 14 Dec 2017 11:01:58 +0000

> That said this sanitization task should be on top of your sparc todo
> list IMHO because the existing /dev/mdesc driver doesn't filter
> anything as of today, so it leaks critical/sensitive data to the OS.

It's root only.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (62 preceding siblings ...)
  2017-12-14 13:44 ` David Miller
@ 2017-12-14 14:59 ` Eric Saint Etienne
  2017-12-14 16:08 ` David Miller
                   ` (12 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Eric Saint Etienne @ 2017-12-14 14:59 UTC (permalink / raw)
  To: sparclinux

As I stated early in the email thread, mdesc sysfs module has the same

permissions as /dev/mdesc chardev. So if you're happy with /dev/mdesc

being root, then you're also happy with mdesc sysfs expsing the same data

with the same perimssions and I don't understand that fuss around the audit.

Please elaborate as I don't understand what's happening here. Thank you.

Eric Saint-Etienne - Principal Linux Kernel Engineer

On 14/12/17 13:44, David Miller wrote:
> From: Eric Saint Etienne <eric.saint.etienne@oracle.com>
> Date: Thu, 14 Dec 2017 11:01:58 +0000
>
>> That said this sanitization task should be on top of your sparc todo
>> list IMHO because the existing /dev/mdesc driver doesn't filter
>> anything as of today, so it leaks critical/sensitive data to the OS.
> It's root only.


^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (63 preceding siblings ...)
  2017-12-14 14:59 ` Eric Saint Etienne
@ 2017-12-14 16:08 ` David Miller
  2017-12-14 17:07 ` Xose Vazquez Perez
                   ` (11 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-12-14 16:08 UTC (permalink / raw)
  To: sparclinux

From: Eric Saint Etienne <eric.saint.etienne@oracle.com>
Date: Thu, 14 Dec 2017 14:59:55 +0000

> Please elaborate as I don't understand what's happening here. Thank
> you.

Well, re-reviewing your patch I do have technical feedback.

You're copying several datastructures and code from the existing MDESC
code.

Please share as much code as possible with arch/sparc/kernel/mdesc.c

Thank you.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (64 preceding siblings ...)
  2017-12-14 16:08 ` David Miller
@ 2017-12-14 17:07 ` Xose Vazquez Perez
  2017-12-18 19:36 ` David Miller
                   ` (10 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Xose Vazquez Perez @ 2017-12-14 17:07 UTC (permalink / raw)
  To: sparclinux

On 01/12/17 19:46, David Miller wrote:

> Also the hypervisor specification URL is completely non-functional,
> the kenai.com stuff went down years ago.

It was archived in:
https://web.archive.org/web/20170409060159/https://kenai.com/projects/hypervisor/downloads
https://web.archive.org/web/20170410000828/https://kenai.com/projects/hypervisor/pages/ReferenceMaterials

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (65 preceding siblings ...)
  2017-12-14 17:07 ` Xose Vazquez Perez
@ 2017-12-18 19:36 ` David Miller
  2017-12-19 18:08 ` Wim Coekaerts
                   ` (9 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-12-18 19:36 UTC (permalink / raw)
  To: sparclinux

From: Xose Vazquez Perez <xose.vazquez@gmail.com>
Date: Thu, 14 Dec 2017 18:07:30 +0100

> On 01/12/17 19:46, David Miller wrote:
> 
>> Also the hypervisor specification URL is completely non-functional,
>> the kenai.com stuff went down years ago.
> 
> It was archived in:
> https://web.archive.org/web/20170409060159/https://kenai.com/projects/hypervisor/downloads
> https://web.archive.org/web/20170410000828/https://kenai.com/projects/hypervisor/pages/ReferenceMaterials

Wim, do you think Oracle can put these critical manuals back up somewhere
permanently?

The fact that developers have to go to the web archive to get what was
a perfectly working public copy is a bit rediculous. :-)

Thanks!

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (66 preceding siblings ...)
  2017-12-18 19:36 ` David Miller
@ 2017-12-19 18:08 ` Wim Coekaerts
  2017-12-19 18:12 ` Mark Cave-Ayland
                   ` (8 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Wim Coekaerts @ 2017-12-19 18:08 UTC (permalink / raw)
  To: sparclinux

Let me see what we can do :)


On 12/18/17 11:36 AM, David Miller wrote:
> From: Xose Vazquez Perez <xose.vazquez@gmail.com>
> Date: Thu, 14 Dec 2017 18:07:30 +0100
>
>> On 01/12/17 19:46, David Miller wrote:
>>
>>> Also the hypervisor specification URL is completely non-functional,
>>> the kenai.com stuff went down years ago.
>> It was archived in:
>> https://web.archive.org/web/20170409060159/https://kenai.com/projects/hypervisor/downloads
>> https://web.archive.org/web/20170410000828/https://kenai.com/projects/hypervisor/pages/ReferenceMaterials
> Wim, do you think Oracle can put these critical manuals back up somewhere
> permanently?
>
> The fact that developers have to go to the web archive to get what was
> a perfectly working public copy is a bit rediculous. :-)
>
> Thanks!


^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (67 preceding siblings ...)
  2017-12-19 18:08 ` Wim Coekaerts
@ 2017-12-19 18:12 ` Mark Cave-Ayland
  2017-12-19 18:47 ` john falkenthal
                   ` (7 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Mark Cave-Ayland @ 2017-12-19 18:12 UTC (permalink / raw)
  To: sparclinux

On 18/12/17 19:36, David Miller wrote:

> From: Xose Vazquez Perez <xose.vazquez@gmail.com>
> Date: Thu, 14 Dec 2017 18:07:30 +0100
> 
>> On 01/12/17 19:46, David Miller wrote:
>>
>>> Also the hypervisor specification URL is completely non-functional,
>>> the kenai.com stuff went down years ago.
>>
>> It was archived in:
>> https://web.archive.org/web/20170409060159/https://kenai.com/projects/hypervisor/downloads
>> https://web.archive.org/web/20170410000828/https://kenai.com/projects/hypervisor/pages/ReferenceMaterials
> 
> Wim, do you think Oracle can put these critical manuals back up somewhere
> permanently?
> 
> The fact that developers have to go to the web archive to get what was
> a perfectly working public copy is a bit rediculous. :-)

Given that it's coming up to Christmas which is the season of goodwill 
and miracles, I might as well also ask if there's any chance of 
resurrecting the old playground.sun.com server and/or copies of the 
documentation that used to be hosted there?

The information was, and in many ways still is, extremely useful for 
people like me working on virtualising old Sun SPARC hardware.


ATB,

Mark.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (68 preceding siblings ...)
  2017-12-19 18:12 ` Mark Cave-Ayland
@ 2017-12-19 18:47 ` john falkenthal
  2017-12-19 22:45 ` Greg Onufer
                   ` (6 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: john falkenthal @ 2017-12-19 18:47 UTC (permalink / raw)
  To: sparclinux

On 12/19/17 10:12 AM, Mark Cave-Ayland wrote:
> On 18/12/17 19:36, David Miller wrote:
>
>> From: Xose Vazquez Perez <xose.vazquez@gmail.com>
>> Date: Thu, 14 Dec 2017 18:07:30 +0100
>>
>>> On 01/12/17 19:46, David Miller wrote:
>>>
>>>> Also the hypervisor specification URL is completely non-functional,
>>>> the kenai.com stuff went down years ago.
>>>
>>> It was archived in:
>>> https://web.archive.org/web/20170409060159/https://kenai.com/projects/hypervisor/downloads 
>>>
>>> https://web.archive.org/web/20170410000828/https://kenai.com/projects/hypervisor/pages/ReferenceMaterials 
>>>
>>
>> Wim, do you think Oracle can put these critical manuals back up 
>> somewhere
>> permanently?
>>
>> The fact that developers have to go to the web archive to get what was
>> a perfectly working public copy is a bit rediculous. :-)
>
> Given that it's coming up to Christmas which is the season of goodwill 
> and miracles, I might as well also ask if there's any chance of 
> resurrecting the old playground.sun.com server and/or copies of the 
> documentation that used to be hosted there?
>
> The information was, and in many ways still is, extremely useful for 
> people like me working on virtualising old Sun SPARC hardware. 
Hi Mark, I'm one of Wim's gang; we're putting together the docs now, and 
we'll take a look at what we had up on playground at the time of its 
demise.  Once the docs are rehosted, we'll send a pointer out, take a 
look and if there is anything missing that you think would be valuable, 
just let us know.  Merry Christmas ;-)

JF

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (69 preceding siblings ...)
  2017-12-19 18:47 ` john falkenthal
@ 2017-12-19 22:45 ` Greg Onufer
  2017-12-20  1:03 ` john falkenthal
                   ` (5 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Greg Onufer @ 2017-12-19 22:45 UTC (permalink / raw)
  To: sparclinux

On Mon, Dec 18, 2017 at 11:36 AM, David Miller <davem@davemloft.net> wrote:>
> >> Also the hypervisor specification URL is completely non-functional, the kenai.com stuff went down years ago.
> >
> > It was archived in:
> > https://web.archive.org/web/20170409060159/https://kenai.com/projects/hypervisor/downloads
> > https://web.archive.org/web/20170410000828/https://kenai.com/projects/hypervisor/pages/ReferenceMaterials
>
> do you think Oracle can put these critical manuals back up somewhere permanently?

FWIW, I've copied the kenai materials to https://sun4v.github.io/

-greg

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (70 preceding siblings ...)
  2017-12-19 22:45 ` Greg Onufer
@ 2017-12-20  1:03 ` john falkenthal
  2017-12-20  1:12 ` David Miller
                   ` (4 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: john falkenthal @ 2017-12-20  1:03 UTC (permalink / raw)
  To: sparclinux


https://oss.oracle.com/sparcdocs/  is now live.

This will be the Oracle hosted location for SPARC/LDoms engineering 
specs and related documents for the developer community.  We've got the 
main virtual machine spec uploaded there now (the last official version, 
v2.0, and the most recent draft v3.0).   More specs are coming, we're 
sifting through what is useful and what is not, but we will err on the 
side of making more available, not less.

JF



^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (71 preceding siblings ...)
  2017-12-20  1:03 ` john falkenthal
@ 2017-12-20  1:12 ` David Miller
  2017-12-20  7:34 ` Mark Cave-Ayland
                   ` (3 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-12-20  1:12 UTC (permalink / raw)
  To: sparclinux

From: john falkenthal <john.falkenthal@oracle.com>
Date: Tue, 19 Dec 2017 17:03:41 -0800

> 
> https://oss.oracle.com/sparcdocs/  is now live.
> 
> This will be the Oracle hosted location for SPARC/LDoms engineering
> specs and related documents for the developer community.  We've got
> the main virtual machine spec uploaded there now (the last official
> version, v2.0, and the most recent draft v3.0).  More specs are
> coming, we're sifting through what is useful and what is not, but we
> will err on the side of making more available, not less.

Thank you.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (72 preceding siblings ...)
  2017-12-20  1:12 ` David Miller
@ 2017-12-20  7:34 ` Mark Cave-Ayland
  2017-12-20  8:54 ` Frans van Berckel
                   ` (2 subsequent siblings)
  76 siblings, 0 replies; 78+ messages in thread
From: Mark Cave-Ayland @ 2017-12-20  7:34 UTC (permalink / raw)
  To: sparclinux

On 19/12/17 18:47, john falkenthal wrote:

> On 12/19/17 10:12 AM, Mark Cave-Ayland wrote:
>> On 18/12/17 19:36, David Miller wrote:
>>
>>> From: Xose Vazquez Perez <xose.vazquez@gmail.com>
>>> Date: Thu, 14 Dec 2017 18:07:30 +0100
>>>
>>>> On 01/12/17 19:46, David Miller wrote:
>>>>
>>>>> Also the hypervisor specification URL is completely non-functional,
>>>>> the kenai.com stuff went down years ago.
>>>>
>>>> It was archived in:
>>>> https://web.archive.org/web/20170409060159/https://kenai.com/projects/hypervisor/downloads 
>>>>
>>>> https://web.archive.org/web/20170410000828/https://kenai.com/projects/hypervisor/pages/ReferenceMaterials 
>>>>
>>>
>>> Wim, do you think Oracle can put these critical manuals back up 
>>> somewhere
>>> permanently?
>>>
>>> The fact that developers have to go to the web archive to get what was
>>> a perfectly working public copy is a bit rediculous. :-)
>>
>> Given that it's coming up to Christmas which is the season of goodwill 
>> and miracles, I might as well also ask if there's any chance of 
>> resurrecting the old playground.sun.com server and/or copies of the 
>> documentation that used to be hosted there?
>>
>> The information was, and in many ways still is, extremely useful for 
>> people like me working on virtualising old Sun SPARC hardware. 

> Hi Mark, I'm one of Wim's gang; we're putting together the docs now, and 
> we'll take a look at what we had up on playground at the time of its 
> demise.  Once the docs are rehosted, we'll send a pointer out, take a 
> look and if there is anything missing that you think would be valuable, 
> just let us know.  Merry Christmas ;-)

Hi John,

Thank you so much, this is absolutely brilliant news!

Are you now the designated contact for documentation requests? Besides 
what was on playground.sun.com there are other things that would be 
really helpful, e.g. in the QEMU sources there are references to the 
sun4u APB/PCI specifications which would be helpful, but I don't think 
were previously ever released outside of NDA?


Many thanks,

Mark.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (73 preceding siblings ...)
  2017-12-20  7:34 ` Mark Cave-Ayland
@ 2017-12-20  8:54 ` Frans van Berckel
  2017-12-20 18:43 ` David Miller
  2018-01-07 22:06 ` Xose Vazquez Perez
  76 siblings, 0 replies; 78+ messages in thread
From: Frans van Berckel @ 2017-12-20  8:54 UTC (permalink / raw)
  To: sparclinux

On Tue, 2017-12-19 at 14:45 -0800, Greg Onufer wrote:
> On Mon, Dec 18, 2017 at 11:36 AM, David Miller <davem@davemloft.net>
> wrote:>
> > > > Also the hypervisor specification URL is completely non-
> > > > functional, the kenai.com stuff went down years ago.
> > > 
> > > It was archived in:
> > > https://web.archive.org/web/20170409060159/https://kenai.com/proj
> > > ects/hypervisor/downloads
> > > https://web.archive.org/web/20170410000828/https://kenai.com/proj
> > > ects/hypervisor/pages/ReferenceMaterials
> > 
> > do you think Oracle can put these critical manuals back up
> > somewhere permanently?
> 
> FWIW, I've copied the kenai materials to https://sun4v.github.io/

Hi Greg,

Oops, all arc caselog links on opensolaris org [1] are automatically
forwarded [2], so there goes something, not as expected. ;-)

[1] http://arc.opensolaris.org/caselog/FWARC/2004/510
[2] https://www.oracle.com/sun/

Thanks,


Frans van Berckel

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (74 preceding siblings ...)
  2017-12-20  8:54 ` Frans van Berckel
@ 2017-12-20 18:43 ` David Miller
  2018-01-07 22:06 ` Xose Vazquez Perez
  76 siblings, 0 replies; 78+ messages in thread
From: David Miller @ 2017-12-20 18:43 UTC (permalink / raw)
  To: sparclinux

From: Greg Onufer <gonufer@jazzhaiku.com>
Date: Tue, 19 Dec 2017 14:45:52 -0800

> On Mon, Dec 18, 2017 at 11:36 AM, David Miller <davem@davemloft.net> wrote:>
>> >> Also the hypervisor specification URL is completely non-functional, the kenai.com stuff went down years ago.
>> >
>> > It was archived in:
>> > https://web.archive.org/web/20170409060159/https://kenai.com/projects/hypervisor/downloads
>> > https://web.archive.org/web/20170410000828/https://kenai.com/projects/hypervisor/pages/ReferenceMaterials
>>
>> do you think Oracle can put these critical manuals back up somewhere permanently?
> 
> FWIW, I've copied the kenai materials to https://sun4v.github.io/

Thanks Greg.

^ permalink raw reply	[flat|nested] 78+ messages in thread

* Re: [PATCH] sparc64: Expose mdesc to sysfs
  2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
                   ` (75 preceding siblings ...)
  2017-12-20 18:43 ` David Miller
@ 2018-01-07 22:06 ` Xose Vazquez Perez
  76 siblings, 0 replies; 78+ messages in thread
From: Xose Vazquez Perez @ 2018-01-07 22:06 UTC (permalink / raw)
  To: sparclinux

On 12/20/2017 08:34 AM, Mark Cave-Ayland wrote:

> Besides what was on playground.sun.com there are other things
> that would be really helpful, e.g. in the QEMU sources there
> are references to the sun4u APB/PCI specifications which would
> be helpful, but I don't think were previously ever released outside of NDA?


wikipedia has some references to archived docs:
https://en.wikipedia.org/wiki/SPARC#External_links

Sun – UltraSPARC Processors Documentation, archive.org copy
Sun – FOSS Open Hardware Documentation, archive.org copy

^ permalink raw reply	[flat|nested] 78+ messages in thread

end of thread, other threads:[~2018-01-07 22:06 UTC | newest]

Thread overview: 78+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-16  5:08 [PATCH] sparc64: Expose mdesc to sysfs Eric Saint Etienne
2017-09-16  6:08 ` David Miller
2017-09-18 14:23 ` Eric Saint Etienne
2017-09-18 16:43 ` David Miller
2017-09-19  6:43 ` Eric Saint Etienne
2017-09-19  6:53 ` John Paul Adrian Glaubitz
2017-09-19  6:58 ` John Paul Adrian Glaubitz
2017-09-19 15:55 ` Anatoly Pugachev
2017-09-19 17:31 ` David Miller
2017-09-19 17:32 ` David Miller
2017-09-19 17:32 ` David Miller
2017-09-19 17:33 ` David Miller
2017-09-19 17:38 ` John Paul Adrian Glaubitz
2017-09-19 17:40 ` John Paul Adrian Glaubitz
2017-09-19 17:42 ` John Paul Adrian Glaubitz
2017-09-19 18:04 ` David Miller
2017-09-19 18:07 ` David Miller
2017-09-19 18:08 ` John Paul Adrian Glaubitz
2017-09-19 18:10 ` David Miller
2017-09-19 18:12 ` David Miller
2017-09-19 18:14 ` David Miller
2017-09-19 18:39 ` John Paul Adrian Glaubitz
2017-09-19 18:40 ` David Miller
2017-09-19 18:44 ` John Paul Adrian Glaubitz
2017-09-19 18:44 ` John Paul Adrian Glaubitz
2017-09-19 19:16 ` Eric Saint Etienne
2017-09-19 19:43 ` John Paul Adrian Glaubitz
2017-09-19 20:24 ` David Miller
2017-09-19 20:25 ` David Miller
2017-09-19 20:29 ` David Miller
2017-09-19 21:24 ` Anatoly Pugachev
2017-09-19 21:57 ` John Paul Adrian Glaubitz
2017-09-19 22:02 ` John Paul Adrian Glaubitz
2017-09-19 22:03 ` Kjetil Oftedal
2017-09-19 22:05 ` John Paul Adrian Glaubitz
2017-09-19 22:06 ` David Miller
2017-09-19 22:07 ` David Miller
2017-09-19 22:08 ` David Miller
2017-09-19 22:09 ` John Paul Adrian Glaubitz
2017-09-19 22:12 ` David Miller
2017-09-19 22:13 ` David Miller
2017-09-19 22:13 ` John Paul Adrian Glaubitz
2017-09-19 22:15 ` David Miller
2017-09-19 22:16 ` John Paul Adrian Glaubitz
2017-09-19 22:25 ` John Paul Adrian Glaubitz
2017-09-22 18:40 ` Anatoly Pugachev
2017-09-23  1:35 ` David Miller
2017-09-23  6:14 ` John Paul Adrian Glaubitz
2017-09-23 16:53 ` David Miller
2017-09-23 19:34 ` Frans van Berckel
2017-09-24 16:23 ` Wim Coekaerts
2017-09-24 20:54 ` Eric Saint Etienne
2017-09-25 21:33 ` David Miller
2017-09-29  9:13 ` Eric Saint Etienne
2017-09-29  9:14 ` Eric Saint-Etienne
2017-12-01 17:15 ` Eric Saint Etienne
2017-12-01 19:46 ` David Miller
2017-12-01 20:37 ` Eric Saint Etienne
2017-12-01 21:28 ` David Miller
2017-12-07 16:40 ` Eric Saint Etienne
2017-12-07 18:05 ` David Miller
2017-12-08  8:17 ` Alexandre Chartre
2017-12-14 11:01 ` Eric Saint Etienne
2017-12-14 13:44 ` David Miller
2017-12-14 14:59 ` Eric Saint Etienne
2017-12-14 16:08 ` David Miller
2017-12-14 17:07 ` Xose Vazquez Perez
2017-12-18 19:36 ` David Miller
2017-12-19 18:08 ` Wim Coekaerts
2017-12-19 18:12 ` Mark Cave-Ayland
2017-12-19 18:47 ` john falkenthal
2017-12-19 22:45 ` Greg Onufer
2017-12-20  1:03 ` john falkenthal
2017-12-20  1:12 ` David Miller
2017-12-20  7:34 ` Mark Cave-Ayland
2017-12-20  8:54 ` Frans van Berckel
2017-12-20 18:43 ` David Miller
2018-01-07 22:06 ` Xose Vazquez Perez

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.