From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760314Ab2BNTor (ORCPT ); Tue, 14 Feb 2012 14:44:47 -0500 Received: from terminus.zytor.com ([198.137.202.10]:43516 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753215Ab2BNToo (ORCPT ); Tue, 14 Feb 2012 14:44:44 -0500 Message-ID: <4F3AB99E.5040705@zytor.com> Date: Tue, 14 Feb 2012 11:44:30 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: David Howells CC: Tony Luck , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds , Arnd Bergmann Subject: Re: [PATCH 21/21] posix_types: Remove fd_set macros References: <4F32A98F.7030400@zytor.com> <1328677745-20121-22-git-send-email-hpa@zytor.com> <1328677745-20121-1-git-send-email-hpa@zytor.com> <8328.1328703626@redhat.com> <16325.1328736262@redhat.com> <4F32E98F.2090909@zytor.com> <30935.1329247114@redhat.com> In-Reply-To: <30935.1329247114@redhat.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/14/2012 11:18 AM, David Howells wrote: > Tony Luck wrote: > >> Adding a #include 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 in . The following macros are defined in 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 header shall define the fd_set type as described in . The header shall define the following as described in : FD_CLR( ) FD_ISSET( ) FD_SET( ) FD_ZERO( ) FD_SETSIZE [...] Inclusion of the header may make visible all symbols from the header. Cleaning up 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 and , but symbols are not permitted to leak into 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.