public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Dave Young <hidave.darkstar@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm] x86 boot : export boot_params via sysfs (forward to Greg)
Date: Wed, 12 Dec 2007 09:45:07 -0800	[thread overview]
Message-ID: <20071212174507.GB16049@kroah.com> (raw)
In-Reply-To: <1197447079.14443.82.camel@caritas-dev.intel.com>

On Wed, Dec 12, 2007 at 04:11:19PM +0800, Huang, Ying wrote:
> On Tue, 2007-12-11 at 23:35 -0800, Greg KH wrote:
> > > +static struct attribute *boot_params_attrs[] = {
> > > +	&boot_params_version_attr.attr,
> > > +	NULL
> > > +};
> > > +
> > > +static struct attribute_group boot_params_attr_group = {
> > > +	.attrs = boot_params_attrs,
> > > +};
> > > +
> > > +static ssize_t boot_params_data_read(struct kobject *kobj,
> > > +				     struct bin_attribute *bin_attr,
> > > +				     char *buf, loff_t off, size_t count)
> > > +{
> > > +	memcpy(buf, (void *)&boot_params + off, count);
> > > +	return count;
> > > +}
> > 
> > Why is the whole structure being exported to userspace directly?
> > Traditionally we only use the binary files for blobs that are not
> > interpreted by the kernel in any way.  Is that what this structure
> > really is?
> 
> The struct boot_params is not the case. But it is too complex (such as
> the struct edd_info in it). It is very complex to output every fields
> include the first level fields until the primary data type. And Peter
> Anvin think it is OK to output it as a big binary file.

Well, I respectively disagree.  sysfs is NOT for exporting various
binary kernel structures to userspace directly.  Again, the binary files
in sysfs are for chunks of memory that are PASS-THROUGH from hardware to
userspace, with no kernel intervention at all.

If you really need such a thing, use debugfs, as the only rule for
debugfs is that there is no rules :)

So I do not agree with this change at this time, and do not want to see
it applied to the tree.

If you really need this kind of information exported to userspace
through sysfs, then expand it all, in a one-text-value-per-file
format.  I would have no objection to that.

thanks,

greg k-h

       reply	other threads:[~2007-12-12 17:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1197443265.14443.59.camel@caritas-dev.intel.com>
     [not found] ` <20071212073502.GA31348@kroah.com>
     [not found]   ` <1197447079.14443.82.camel@caritas-dev.intel.com>
2007-12-12 17:45     ` Greg KH [this message]
2007-12-12 19:15       ` [PATCH -mm] x86 boot : export boot_params via sysfs (forward to Greg) Dave Jones
2007-12-12 22:18         ` Greg KH

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20071212174507.GB16049@kroah.com \
    --to=greg@kroah.com \
    --cc=akpm@linux-foundation.org \
    --cc=hidave.darkstar@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

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

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