On 02/14/2012 11:18 AM, David Howells wrote: > Tony Luck <tony.luck@xxxxxxxxx> 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_SETSIZE __FD_SETSIZE #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 <sys/select.h>. The <sys/time.h> header shall define the following as described in <sys/select.h>: FD_CLR( ) FD_ISSET( ) FD_SET( ) FD_ZERO( ) FD_SETSIZE [...] 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.) -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
