1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
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.
<pinotree> d'oh, broken defines for ioctl()!
<pinotree> http://paste.debian.net/45021/ ← any idea about this? looks like something fishy with the SIO* defines
<pinotree> tschwinge: ↑ know anything about this?
<pinotree> #define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← looks like it is missing for bits/ioctls.h
<pinotree> eglibc patch submitted-ioctl-unsigned-size_t.diff should be pimped a bit
<pinotree> 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
<youpi> that's possible
<pinotree> it has a ioctrl() using an id with a value having type 'struct arpreq'
<youpi> ah, that's not a bug then
<youpi> see the ioctl section of the porting page of the wiki
<pinotree> due to the sort of "mangling" done in bits/ioctrls.h, there should be an helper macro for the size of the struct arpreq
<pinotree> +#define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← adding this before any header was enough
* pinotree looks
<youpi> it's not to be done so simply
<youpi> see the page :)
<youpi> I'm afraid _IOT_arpreq can't be properly defined
* pinotree is not finding it...
<pinotree> the closest i see is http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html
<youpi> that's it yes
<youpi> I mean, that's the kind of thing
<youpi> but not the wiki page, let me look
<youpi> http://www.gnu.org/software/hurd/hurd/porting/guidelines.html
<pinotree> i also saw a glib patch adding few types like that (char, short, int)
<youpi> yes that's the same kind of thing
<pinotree> i see
<youpi> 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
<pinotree> hmmm, sockaddr,sockaddr,int,sockaddr,char[16]
<pinotree> so basically it would support at most 3 elements in a passed struct?
<pinotree> s/elements/fields/
<youpi> 3 kinds of fields
<youpi> as you provide a count
<pinotree> youpi: so basically: #define _IOT_arpreq _IOT (_IOTS (struct sockaddr), 3, _IOTS (int), 1, _IOTS (char), 16) ?
<pinotree> ie the order of the fields in the struct does not matter, it seems?
<youpi> the order of the fields does matter
<youpi> as this encodes how mig will read the struct to send them
<pinotree> uhm
<youpi> also, _IOTS(struct sockaddr) won't work
<pinotree> yeah i should define it too
<youpi> no, it even needs to be replaced by its content
<pinotree> ah
<pinotree> it is possible to compose the _IOTS()?
<pinotree> (to build structs with more than 3 kind of fields)
<youpi> no
<pinotree> d'oh
<youpi> that's a hard shortcoming of the whole ioctl encoding
* pinotree scratches his head
<youpi> there's no way but redefining ioctl(), really
<youpi> it was a funny trick to encode it this way, but unrealistic
<pinotree> i see, yes
<youpi> not to mention ioctls which contain pointers, which just can not be passed to mig
<pinotree> indeed
<youpi> actually it's not mach's ioctl issue
<youpi> as mach doesn't know ioctl
<youpi> but the hurd ioctl interface
<pinotree> right
<youpi> which might end up in mach, other processes, other machines, etc.
* pinotree s/Mach/Hurd/ :)
|
