[lkml]   [2012]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 21/21] posix_types: Remove fd_set macros
    On 02/14/2012 11:18 AM, David Howells wrote:
    > Tony Luck <> wrote:
    >> Adding a #include <linux/string.h> to include/linux/time.h fixes them for me.
    > Which is one of the reasons I'd rather not see these things cropping up in
    > linux/time.h. Either put them in linux/select.h (mirroring userspace) or
    > stick them in linux/poll.h with the rest of the polling paraphernalia.
    > __FD_SET() and co aren't exported to userspace anyway, as I understand it, so
    > it shouldn't hurt to bung them in linux/poll.h, and if they are exported to
    > userspace, they should stay in posix_types.h, shouldn't they?
    > To support this, at least three #includes will have to be added to
    > linux/time.h: linux/posix_types.h (which is fair enough), linux/bitops.h and
    > linux/string.h.

    We can do that, but we'd almost certainly have to #include
    <linux/select.h> in <linux/time.h>. The following macros are defined in
    <linux/time.h> and *exported to userspace*:

    #define NFDBITS __NFDBITS

    #define FD_SET(fd,fdsetp) __FD_SET(fd,fdsetp)
    #define FD_CLR(fd,fdsetp) __FD_CLR(fd,fdsetp)
    #define FD_ISSET(fd,fdsetp) __FD_ISSET(fd,fdsetp)
    #define FD_ZERO(fdsetp) __FD_ZERO(fdsetp)

    Now, this largely mimics what has happened in userspace over time; to
    quote POSIX:

    The <sys/time.h> header shall define the fd_set type as described in

    The <sys/time.h> header shall define the following as described in
    FD_CLR( )
    FD_ISSET( )
    FD_SET( )
    FD_ZERO( )


    Inclusion of the <sys/time.h> header may make visible all symbols from
    the <sys/select.h> header.

    Cleaning up <linux/time.h> would indeed be a worthwhile goal -- it's not
    clear to me that it can safely be used to build a POSIX-compliant
    userspace. In particular, it mixes the functions of <sys/time.h> and
    <time.h>, but <time.h> symbols are not permitted to leak into
    <sys/time.h> space as far as I read the specification. However, this
    feels like a slightly orthogonal task (in fact, it might belong more in
    your uabi work.)

    H. Peter Anvin, Intel Open Source Technology Center
    I work for Intel. I don't speak on their behalf.

     \ /
      Last update: 2012-02-14 20:47    [W:0.029 / U:93.668 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site