linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Tom Rini <trini@kernel.crashing.org>
To: Leigh Brown <leigh@solinno.co.uk>
Cc: hollis@austin.ibm.com, linuxppc-dev@lists.linuxppc.org,
	Sven Dickert <Sven.Dickert@planb.de>
Subject: Re: /proc/residual (CONFIG_PREP_PROCRESIDUAL)
Date: Tue, 29 Jan 2002 15:03:37 -0700	[thread overview]
Message-ID: <20020129220337.GG25973@opus.bloom.county> (raw)
In-Reply-To: <Pine.LNX.4.33.0201292138010.3937-100000@fridge.solinno.co.uk>


On Tue, Jan 29, 2002 at 09:47:02PM +0000, Leigh Brown wrote:

> On Tue, 29 Jan 2002 hollis@austin.ibm.com wrote:
>
> > On Tue, Jan 29, 2002 at 04:08:43PM +0000, Leigh Brown wrote:
> > >
> > > It works for me.  The comment needs to be changed to say it can't be a
> > > module.  I've attached the version I came up with, mainly because I went
> > > to some trouble to do it.  Differences:
> > >
> > > 2. Remove #ifdef __KERNEL__ from header file for use space utility
> >
> > This encourages user applications to include kernel header files, which has
> > been deemed ungood. I believe there should be many lengthy threads on the
> > subject in the lkml archives, but more practically speaking Paul has said he'd
> > be perfectly happy if all kernel headers were completely protected from user
> > space.
>
> Surely that can't be true.  What about asm/errno.h?  I thought you just
> put #ifdef __KERNEL__ around stuff you don't want to export to user space.
> In the case of asm/residual.h it all needs to be exported to user space.
> The alternative is to simply clone the file, which seems a bit silly.

There's a few legacy files which unfortunatly can't be clamped down on.
In general you are supposed to copy the file and be done with it.  In
fact, if I ever wanted to read the residual image from my PReP box
(usually off) on my x86 (which I'm typing on right now), I'd need to do
this anyways since x86 won't have '<asm/residual.h>'.

> > > 4. Only create entry if residual size > 0 'coz what you can't see won't
> > >    hurt you + eliminate chance of people wondering why they are getting an
> > >    error trying to read it.
> >
> > I don't like that, because it leaves you wondering if you compiled in residual
> > support at all... I'd much rather have it be 0 length.
>
> Okay.  I think the best behaviour is to simply return 0 bytes if there
> is no residual data and let lsresidual interpret that as being no
> residual data.

If we don't have any residual data, shouldn't we be returning a 0 byte
file anyhow?  I didn't explicitly test this, but in the original version
I got from Sven/Hollis, no residual data gave me an empty
/proc/residual.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2002-01-29 22:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-28 16:08 /proc/residual (CONFIG_PREP_PROCRESIDUAL) Tom Rini
2002-01-29 16:08 ` Leigh Brown
2002-01-29 16:56   ` hollis
2002-01-29 21:47     ` Leigh Brown
2002-01-29 22:03       ` Tom Rini [this message]
2002-01-30 20:47         ` Leigh Brown
2002-01-30 20:41           ` Tom Rini

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=20020129220337.GG25973@opus.bloom.county \
    --to=trini@kernel.crashing.org \
    --cc=Sven.Dickert@planb.de \
    --cc=hollis@austin.ibm.com \
    --cc=leigh@solinno.co.uk \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /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;
as well as URLs for NNTP newsgroup(s).