lkml.org 
[lkml]   [2015]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/5] tools: Add err.h with ERR_PTR PTR_ERR interface
    Em Tue, Sep 08, 2015 at 04:22:39PM -0400, Raphaël Beamonte escreveu:
    > 2015-09-07 4:38 GMT-04:00 Jiri Olsa <jolsa@kernel.org>:
    > > Adding part of the kernel's <linux/err.h> interface:
    > > inline void * __must_check ERR_PTR(long error);
    > > inline long __must_check PTR_ERR(__force const void *ptr);
    > > inline bool __must_check IS_ERR(__force const void *ptr);
    > >
    > > it will be used to propagate error through pointers
    > > in following patches.
    > >
    > > Link: http://lkml.kernel.org/n/tip-ufgnyf683uab69anmmrabgdf@git.kernel.org
    > > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    > > ---
    > > tools/include/linux/err.h | 49 +++++++++++++++++++++++++++++++++++++++++++++++
    > > 1 file changed, 49 insertions(+)
    > > create mode 100644 tools/include/linux/err.h
    > >
    > > diff --git a/tools/include/linux/err.h b/tools/include/linux/err.h
    > > new file mode 100644
    > > index 000000000000..c9ada48f5156
    > > --- /dev/null
    > > +++ b/tools/include/linux/err.h
    > > @@ -0,0 +1,49 @@
    > > +#ifndef __TOOLS_LINUX_ERR_H
    > > +#define __TOOLS_LINUX_ERR_H
    > > +
    > > +#include <linux/compiler.h>
    > > +#include <linux/types.h>
    > > +
    > > +#include <asm/errno.h>
    > > +
    > > +/*
    > > + * Original kernel header comment:
    > > + *
    > > + * Kernel pointers have redundant information, so we can use a
    > > + * scheme where we can return either an error code or a normal
    > > + * pointer with the same return value.
    > > + *
    > > + * This should be a per-architecture thing, to allow different
    > > + * error and pointer decisions.
    > > + *
    > > + * Userspace note:
    > > + * The same principle works for userspace, because 'error' pointers
    > > + * fall down to the unused hole far from user space, as described
    > > + * in Documentation/x86/x86_64/mm.txt for x86_64 arch:
    > > + *
    > > + * 0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm hole caused by [48:63] sign extension
    > > + * ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
    > > + *
    > > + * It should be the same case for other architectures, because
    > > + * this code is used in generic kernel code.
    > > + */
    > > +#define MAX_ERRNO 4095
    > > +
    > > +#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
    > > +
    > > +static inline void * __must_check ERR_PTR(long error)
    > > +{
    > > + return (void *) error;
    > > +}
    > > +
    > > +static inline long __must_check PTR_ERR(__force const void *ptr)
    > > +{
    > > + return (long) ptr;
    > > +}
    > > +
    > > +static inline bool __must_check IS_ERR(__force const void *ptr)
    > > +{
    > > + return IS_ERR_VALUE((unsigned long)ptr);
    > > +}
    > > +
    > > +#endif /* _LINUX_ERR_H */
    > > --
    > > 2.4.3
    >
    > Perhaps a dumb question, but it seems the code is exactly the same as
    > in linux/err.h besides the part of the comment you added. Why not
    > using that file directly in the other patches then?

    We can't do that.

    Read:

    commit 3f735377bfd6567d80815a6242c147211963680a
    Author: Arnaldo Carvalho de Melo <acme@redhat.com>
    Date: Sun Jul 5 22:48:21 2015 -0300

    tools: Copy lib/rbtree.c to tools/lib/

    So that we can remove kernel specific stuff we've been stubbing out via
    a tools/include/linux/export.h that gets removed in this patch and to
    avoid breakages in the future like the one fixed recently where
    rcupdate.h started being used in rbtree.h.


    --------------------------

    There are more copies like that, but the explanation above should be
    enough, no?


    - Arnaldo


    \
     
     \ /
      Last update: 2015-09-08 23:21    [W:7.396 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site