From: Michael Neuling <mikey@neuling.org>
To: "prodyut hazarika" <prodyuth@gmail.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Making __copy_tofrom_user more readable for powerpc (arch/powerpc/lib/copy_32.S)
Date: Fri, 11 Jul 2008 16:50:10 +1000 [thread overview]
Message-ID: <22167.1215759010@neuling.org> (raw)
In-Reply-To: <49c0ff980807101644x6ffb9a66x3f73c72f1be86e3@mail.gmail.com>
In message <49c0ff980807101644x6ffb9a66x3f73c72f1be86e3@mail.gmail.com> you wro
te:
> Hi all,
> I am trying to optimize the __copy_tofrom_user function for PPC4xx,
> and I would want to know why the exception handling code has been made
> so complicated. All the fixup code should do is to store the number of
> bytes that failed in copy in r3 and return back.
>
> The current code tries to copy one byte at a time after read fault. I
> don't understand why that is necessary. It then clears out the
> destination. All these logic has made the code very unfriendly to
> read.
Would a multibyte read be guaranteed to be aligned?
> I have a version which just keeps a count of bytes copied till any
> fault happened. Then for any exception, I just substract this value
> from the total number of bytes to be copied, and store in r3 and
> return back. This is the common fixup code for all paths. It makes the
> fixup code much more readable like other architectures (eg. x86).
>
> My questions are:
> 1) Why do we need to distinguish between load and store failure? If
> either load or store fails, the copy did not go thru. But the code
> sets r9 to 0 for load failure, and r9 to 1 for write failure. Why do
> we need to care for that?
>
> 2) For read failure, why do we clear out the destination (lines 509 to
> 529 in arch/powerpc/lib/copy_32.S)? Other architecture don't do that.
Which version of the code are you referring to here? Can you give us a
git SHA1?
Clean up patches are welcome. Maybe it would be best to post what you
have as an RFC patch. Then people can take a closer/easier look at your
cleanups and/or try them out.
Mikey
>
> I would appreciate any comments.
>
> Thanks,
> Prodyut
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
next prev parent reply other threads:[~2008-07-11 6:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-10 23:44 Making __copy_tofrom_user more readable for powerpc (arch/powerpc/lib/copy_32.S) prodyut hazarika
2008-07-11 6:50 ` Michael Neuling [this message]
2008-07-11 7:02 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2008-07-10 18:06 prodyut hazarika
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=22167.1215759010@neuling.org \
--to=mikey@neuling.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=prodyuth@gmail.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 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.