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
next parent 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