From 457e98160dec549504ec3f8b15b94a0479b51868 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 30 Jul 2010 16:34:37 +0200 Subject: open_issues/glibc_ioctls: New. --- open_issues/glibc_ioctls.mdwn | 72 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 open_issues/glibc_ioctls.mdwn (limited to 'open_issues') diff --git a/open_issues/glibc_ioctls.mdwn b/open_issues/glibc_ioctls.mdwn new file mode 100644 index 00000000..14329d0f --- /dev/null +++ b/open_issues/glibc_ioctls.mdwn @@ -0,0 +1,72 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + d'oh, broken defines for ioctl()! + http://paste.debian.net/45021/ ← any idea about this? looks like something fishy with the SIO* defines + tschwinge: ↑ know anything about this? + #define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← looks like it is missing for bits/ioctls.h + eglibc patch submitted-ioctl-unsigned-size_t.diff should be pimped a bit + + youpi: while trying to compile ossp-uuid (needed by pgsql 8.4, needed by various other stuff), i found a bug in a hurd libc header + that's possible + it has a ioctrl() using an id with a value having type 'struct arpreq' + ah, that's not a bug then + see the ioctl section of the porting page of the wiki + due to the sort of "mangling" done in bits/ioctrls.h, there should be an helper macro for the size of the struct arpreq + +#define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← adding this before any header was enough + * pinotree looks + it's not to be done so simply + see the page :) + I'm afraid _IOT_arpreq can't be properly defined + * pinotree is not finding it... + the closest i see is http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html + that's it yes + I mean, that's the kind of thing + but not the wiki page, let me look + http://www.gnu.org/software/hurd/hurd/porting/guidelines.html + i also saw a glib patch adding few types like that (char, short, int) + yes that's the same kind of thing + i see + setting it to _IOT_SIMPLE(struct arpreq) would probably work with 32bit gnumach and 32bit userland, but may not with e.g. 64bit gnumach and 32bit userland and such + hmmm, sockaddr,sockaddr,int,sockaddr,char[16] + so basically it would support at most 3 elements in a passed struct? + s/elements/fields/ + 3 kinds of fields + as you provide a count + youpi: so basically: #define _IOT_arpreq _IOT (_IOTS (struct sockaddr), 3, _IOTS (int), 1, _IOTS (char), 16) ? + ie the order of the fields in the struct does not matter, it seems? + the order of the fields does matter + as this encodes how mig will read the struct to send them + uhm + also, _IOTS(struct sockaddr) won't work + yeah i should define it too + no, it even needs to be replaced by its content + ah + it is possible to compose the _IOTS()? + (to build structs with more than 3 kind of fields) + no + d'oh + that's a hard shortcoming of the whole ioctl encoding + * pinotree scratches his head + there's no way but redefining ioctl(), really + it was a funny trick to encode it this way, but unrealistic + i see, yes + not to mention ioctls which contain pointers, which just can not be passed to mig + indeed + actually it's not mach's ioctl issue + as mach doesn't know ioctl + but the hurd ioctl interface + right + which might end up in mach, other processes, other machines, etc. + * pinotree s/Mach/Hurd/ :) -- cgit v1.2.3