Date: Tue, 7 Jan 2014 16:52:30 -0700 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@freebsd.org> Cc: Bruce Evans <bde@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Using sys/types.h types in sys/socket.h Message-ID: <5821DA91-E9C7-4D1A-A108-63E74CFF1FC5@bsdimp.com> In-Reply-To: <CAJ-Vmom3FQOb1ZQTwbmbSiT90N6tmKOoPg8JPQAapkJg2TXqFA@mail.gmail.com> References: <CAJ-Vmo=MWPQWfP9duWPPwaKee5Zp9Gemj3GKqE8=bxkjn_1YYA@mail.gmail.com> <9C1291B5-215B-440E-B8B0-6308840F755C@bsdimp.com> <CAJ-Vmom3FQOb1ZQTwbmbSiT90N6tmKOoPg8JPQAapkJg2TXqFA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 7, 2014, at 2:20 PM, Adrian Chadd wrote:
> On 17 December 2013 07:42, Warner Losh <imp@bsdimp.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5821DA91-E9C7-4D1A-A108-63E74CFF1FC5>