diff mbox series

Documentation: fix spelling mistake, EACCESS -> EACCES

Message ID 20181026172549.3628-1-colin.king@canonical.com
State New
Headers show
Series Documentation: fix spelling mistake, EACCESS -> EACCES | expand

Checks

Context Check Description
snowpatch_ozlabs/build-ppc32 success Test build-ppc32 on branch next
snowpatch_ozlabs/build-ppc64e success Test build-ppc64e on branch next
snowpatch_ozlabs/build-ppc64be success Test build-ppc64be on branch next
snowpatch_ozlabs/build-ppc64le success Test build-ppc64le on branch next
snowpatch_ozlabs/checkpatch success Test checkpatch on branch next
snowpatch_ozlabs/apply_patch success next/apply_patch Successfully applied

Commit Message

Colin Ian King Oct. 26, 2018, 5:25 p.m. UTC
From: Colin Ian King <colin.king@canonical.com>

Trivial fix to a spelling mistake of the error access name EACCESS,
rename to EACCES

Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 Documentation/filesystems/spufs.txt | 2 +-
 Documentation/gpu/drm-uapi.rst      | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

Comments

Miguel Ojeda Oct. 26, 2018, 6:20 p.m. UTC | #1
On Fri, Oct 26, 2018 at 7:27 PM Colin King <colin.king@canonical.com> wrote:
>
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to a spelling mistake of the error access name EACCESS,
> rename to EACCES

? It is not a typo, it is the name of the error (POSIX). Same thing
for the rest of the patches.

Cheers,
Miguel
Matthew Wilcox Oct. 26, 2018, 6:40 p.m. UTC | #2
On Fri, Oct 26, 2018 at 08:20:12PM +0200, Miguel Ojeda wrote:
> On Fri, Oct 26, 2018 at 7:27 PM Colin King <colin.king@canonical.com> wrote:
> >
> > From: Colin Ian King <colin.king@canonical.com>
> >
> > Trivial fix to a spelling mistake of the error access name EACCESS,
> > rename to EACCES
> 
> ? It is not a typo, it is the name of the error (POSIX). Same thing
> for the rest of the patches.

Are you sure?  From open(2):

       EACCES The  requested access to the file is not allowed, or search per‐
              mission is denied for one of the directories in the path  prefix
              of  pathname,  or the file did not exist yet and write access to
              the parent directory is not  allowed.   (See  also  path_resolu‐
              tion(7).)

include/uapi/asm-generic/errno-base.h:#define   EACCES          13      /* Permission denied */
Miguel Ojeda Oct. 26, 2018, 6:53 p.m. UTC | #3
On Fri, Oct 26, 2018 at 8:40 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Fri, Oct 26, 2018 at 08:20:12PM +0200, Miguel Ojeda wrote:
> > On Fri, Oct 26, 2018 at 7:27 PM Colin King <colin.king@canonical.com> wrote:
> > >
> > > From: Colin Ian King <colin.king@canonical.com>
> > >
> > > Trivial fix to a spelling mistake of the error access name EACCESS,
> > > rename to EACCES
> >
> > ? It is not a typo, it is the name of the error (POSIX). Same thing
> > for the rest of the patches.
>
> Are you sure?  From open(2):
>
>        EACCES The  requested access to the file is not allowed, or search per‐
>               mission is denied for one of the directories in the path  prefix
>               of  pathname,  or the file did not exist yet and write access to
>               the parent directory is not  allowed.   (See  also  path_resolu‐
>               tion(7).)
>
> include/uapi/asm-generic/errno-base.h:#define   EACCES          13      /* Permission denied */

I thought you were doing the reverse change. Never mind! :-)

(Btw, the POSIX reference is
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html#tag_13_09,
in case you want to include it or are curious)

Cheers,
Miguel
Miguel Ojeda Oct. 26, 2018, 6:54 p.m. UTC | #4
On Fri, Oct 26, 2018 at 8:53 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Fri, Oct 26, 2018 at 8:40 PM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Fri, Oct 26, 2018 at 08:20:12PM +0200, Miguel Ojeda wrote:
> > > On Fri, Oct 26, 2018 at 7:27 PM Colin King <colin.king@canonical.com> wrote:
> > > >
> > > > From: Colin Ian King <colin.king@canonical.com>
> > > >
> > > > Trivial fix to a spelling mistake of the error access name EACCESS,
> > > > rename to EACCES
> > >
> > > ? It is not a typo, it is the name of the error (POSIX). Same thing
> > > for the rest of the patches.
> >
> > Are you sure?  From open(2):
> >
> >        EACCES The  requested access to the file is not allowed, or search per‐
> >               mission is denied for one of the directories in the path  prefix
> >               of  pathname,  or the file did not exist yet and write access to
> >               the parent directory is not  allowed.   (See  also  path_resolu‐
> >               tion(7).)
> >
> > include/uapi/asm-generic/errno-base.h:#define   EACCES          13      /* Permission denied */
>
> I thought you were doing the reverse change. Never mind! :-)
>
> (Btw, the POSIX reference is
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html#tag_13_09,
> in case you want to include it or are curious)

Sorry Matthew, thought I was answering to Colin. I should go to rest.

Cheers,
Miguel
Jonathan Corbet Nov. 7, 2018, 10:31 p.m. UTC | #5
On Fri, 26 Oct 2018 18:25:49 +0100
Colin King <colin.king@canonical.com> wrote:

> Trivial fix to a spelling mistake of the error access name EACCESS,
> rename to EACCES
> 
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
>  Documentation/filesystems/spufs.txt | 2 +-
>  Documentation/gpu/drm-uapi.rst      | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)

Applied, thanks.  

This is the first patch to spufs.txt since 2006...I wonder if that stuff
is being used by anybody...

jon
Jeremy Kerr Nov. 8, 2018, 12:38 a.m. UTC | #6
Hi Jon,

>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>> ---
>>   Documentation/filesystems/spufs.txt | 2 +-
>>   Documentation/gpu/drm-uapi.rst      | 4 ++--
>>   2 files changed, 3 insertions(+), 3 deletions(-)
> 
> Applied, thanks.
> 
> This is the first patch to spufs.txt since 2006...I wonder if that stuff
> is being used by anybody...

Anyone who is using the vector processors on the Cell BE processors will
be using it. However, that hardware is becoming pretty rare now.

We'll want to remove the spufs bits if/when we drop support for the cell
platforms (IBM QSxx, PS3, celleb). mpe: any ides on that? Do you have a 
policy for dropping platform support?

Cheers,


Jeremy
Michael Ellerman Nov. 12, 2018, 12:57 p.m. UTC | #7
Jeremy Kerr <jk@ozlabs.org> writes:
> Hi Jon,
>
>>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>>> ---
>>>   Documentation/filesystems/spufs.txt | 2 +-
>>>   Documentation/gpu/drm-uapi.rst      | 4 ++--
>>>   2 files changed, 3 insertions(+), 3 deletions(-)
>> 
>> Applied, thanks.
>> 
>> This is the first patch to spufs.txt since 2006...I wonder if that stuff
>> is being used by anybody...
>
> Anyone who is using the vector processors on the Cell BE processors will
> be using it. However, that hardware is becoming pretty rare now.
>
> We'll want to remove the spufs bits if/when we drop support for the cell
> platforms (IBM QSxx, PS3, celleb). mpe: any ides on that? Do you have a 
> policy for dropping platform support?

I don't have a policy. We discussed it a bit at maintainer summit, that
basically boiled down to stuff should get removed when it is not used
much and/or is causing undue maintenance burden - both of which are
fairly arbitrary criteria.

My feeling is spufs is not causing anyone much work, it does get hit by
some VFS updates but it's just one of many many filesystems, so the
incremental overhead is pretty small I think - though VFS people may
disagree :)

I still have a working IBM QS22, and Geoff is still maintaining PS3,
celleb is gone.

Basically we're keeping it around in case people are still using it on
their PS3s. I don't know how we gauge how many people that is without
removing support and seeing who is annoyed. But even if we did that a
lot of folks will probably not notice for months to years, and when they
do notice they'll just bin their PS3s rather than telling us.

But maybe Geoff has a better feel for how many people (other than him)
are still running upstream on PS3s.

cheers
Geoff Levand Nov. 12, 2018, 8:15 p.m. UTC | #8
Hi Everyone,

On 11/12/2018 04:57 AM, Michael Ellerman wrote:
> But maybe Geoff has a better feel for how many people (other than him)
> are still running upstream on PS3s.

There are still PS3 users out there.  They are hobbyists who
generally don't post to Linux kernel mailing lists.  I usually
get one or two mail or IRC inquiries every month, many asking
how to get a recent kernel running.

I try keep my dev repo at k.org up to the latest -rc release
and tested on the retail PS3.  For more info see:

  https://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git
  https://www.kernel.org/pub/linux/kernel/people/geoff/cell/README

-Geoff
diff mbox series

Patch

diff --git a/Documentation/filesystems/spufs.txt b/Documentation/filesystems/spufs.txt
index 1343d118a9b2..eb9e3aa63026 100644
--- a/Documentation/filesystems/spufs.txt
+++ b/Documentation/filesystems/spufs.txt
@@ -452,7 +452,7 @@  RETURN VALUE
 
 
 ERRORS
-       EACCESS
+       EACCES
               The  current  user does not have write access on the spufs mount
               point.
 
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index a2214cc1f821..f2f079e91b4c 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -190,11 +190,11 @@  ENOSPC:
 
         Simply running out of kernel/system memory is signalled through ENOMEM.
 
-EPERM/EACCESS:
+EPERM/EACCES:
         Returned for an operation that is valid, but needs more privileges.
         E.g. root-only or much more common, DRM master-only operations return
         this when when called by unpriviledged clients. There's no clear
-        difference between EACCESS and EPERM.
+        difference between EACCES and EPERM.
 
 ENODEV:
         Feature (like PRIME, modesetting, GEM) is not supported by the driver.