From owner-freebsd-arch@FreeBSD.ORG Wed Jan 8 00:22:20 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3FD3EB4 for ; Wed, 8 Jan 2014 00:22:19 +0000 (UTC) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AEAC01FDC for ; Wed, 8 Jan 2014 00:22:18 +0000 (UTC) Received: by mail-gg0-f172.google.com with SMTP id q6so166961ggc.17 for ; Tue, 07 Jan 2014 16:22:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+CrGwtR5mlp6VuOl7gVGiuotz0SOjRUCEQWVuJdXLs0=; b=PmsK1mleatO7gG44PYPVDQRNcPqgFsOmxsEoW81rCrgxqgXFgiVcXJ2fdKjwsGU1QM PovhMK3/JNhxDMz39lKeCUw/CTiGsmjeN0rHyitekfr3ujkNP518jI+qc5LrxlMoq6Vn 0R32PHFgnnV1yvsoJHmzL9ow7+tx2d3szqSv4z219+tGbAAhUafZeKjX299P5K00RpIq EjFCSVnb8ZJm7wZabfR1Uqv5obgp8pVqc17bVsauWVghg1dSF6m/4bsUOuMJk7YKTUio XpUCter7kh4dHVoDL3CRtLafNblZKFsayf+pErWDn960n1m3xNntTRoBg9tIOYILmyAP Z1BA== X-Gm-Message-State: ALoCoQklMpoalt+aLphW3KmU9M4WYhAn5LHooAFXb46zj4sEODfnDtVsHmiW2TgB+QEDnq+bzNIl X-Received: by 10.236.172.33 with SMTP id s21mr4760768yhl.71.1389138752137; Tue, 07 Jan 2014 15:52:32 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id m9sm26243956yha.2.2014.01.07.15.52.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 15:52:31 -0800 (PST) Sender: Warner Losh Subject: Re: Using sys/types.h types in sys/socket.h Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 7 Jan 2014 16:52:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5821DA91-E9C7-4D1A-A108-63E74CFF1FC5@bsdimp.com> References: <9C1291B5-215B-440E-B8B0-6308840F755C@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) Cc: Bruce Evans , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 00:22:20 -0000 On Jan 7, 2014, at 2:20 PM, Adrian Chadd wrote: > On 17 December 2013 07:42, Warner Losh wrote: >> The tl;dr version: use sys/_types.h and use the usual conventions to = avoid namespace pollution. I read Bruce's reply, and I think I'm saying = the same things he is... >=20 > Yup, I've done that bit. >=20 >> Warner >>=20 >> On Dec 17, 2013, at 1:23 AM, Adrian Chadd wrote: >>=20 >>> Hi, >>>=20 >>> I have a patch to implement some new sendfile functionality, but = this >>> involves adding stuff to sys/socket.h: >>>=20 >>> Index: sys/sys/socket.h >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- sys/sys/socket.h (revision 258883) >>> +++ sys/sys/socket.h (working copy) >>> @@ -577,11 +577,27 @@ >>> }; >>>=20 >>> /* >>> + * sendfile(2) kqueue information >>> + */ >>> +struct sf_hdtr_kq { >>> + int kq_fd; /* kq fd to post completion events on */ >>> + uint32_t kq_flags; /* extra flags to pass in */ >>> + void *kq_udata; /* user data pointer */ >>> + uintptr_t kq_ident; /* ident (from userland?) */ >>> +}; >>=20 >> This is a terrible interface. Or I'd say that the ordering of the = elements in this structure is suboptimal. Having the uint32_t in the = middle like that causes badness. Guess not much can be done about that = given that fd must be an int, eh? >=20 > I'm open to an alternate interface that doesn't require new syscalls > or syscall modification. Yeah, the definition of an fd here is an > 'int'. I could always turn it into an int32_t to fix the size but > would that be "ok" ? I'm not sure it is worth fixing in this way, since it is counter to all = the other uses of fd in the system, so maybe this is the best we can = have given those constraints... Warner