| Message ID | 20181026172549.3628-1-colin.king@canonical.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | Documentation: fix spelling mistake, EACCESS -> EACCES | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | next/apply_patch Successfully applied |
| snowpatch_ozlabs/checkpatch | success | Test checkpatch on branch next |
| snowpatch_ozlabs/build-ppc64le | success | Test build-ppc64le on branch next |
| snowpatch_ozlabs/build-ppc64be | success | Test build-ppc64be on branch next |
| snowpatch_ozlabs/build-ppc64e | success | Test build-ppc64e on branch next |
| snowpatch_ozlabs/build-ppc32 | success | Test build-ppc32 on branch next |
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
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 */
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
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
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
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
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
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 --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.