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
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
[[!meta copyright="Copyright © 2010, 2014 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/ :)
# `TIOCCONS`
## IRC, freenode, #hurd, 2014-02-05
<gnu_srs> Hi, anybody have time to look at what fails with: ioctl(0,
TIOCCONS, NULL)?
<gnu_srs> found a program doing the same function call as bootlogd:
http://paste.debian.net/80231/
<gnu_srs> rpctrace: http://paste.debian.net/80232/
<youpi> gnu_srs: it seems there is a misunderstanding between linux and
*bsd on this one
<youpi> to be able to work on *bsd (and on hurd too), the source code
should replace its NULL parameter with the address of an integer
containing 1
<youpi> see
http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022116.html
for the bsd implementation, for instance
<gnu_srs> youpi: replacing 0 with &i where int i=1 gives: TIOCCONS:
Inappropriate ioctl for device
<youpi> so be it, but that's clearly needed to be able to work on bsd
<youpi> and probably the implementation is just missing on the Hurd for now
<gnu_srs> jus to be clear: do you mean 0 or NULL in: ioctl(0, TIOCCONS,
NULL)?
<youpi> yes, for instance there is an implementation do_tiocsctty in glibc,
but no to_tioccons
<youpi> I mean NULL
<gnu_srs> OK, that's where I changed, the first argument id the FD
<youpi> well, when I wrote "NULL", I really meant "NULL" ...
<gnu_srs> yes sure, so you say that it is not yet implemented?
<youpi> yes, for instance there is an implementation do_tiocsctty in glibc,
but no to_tioccons
<gnu_srs> easy to do?
<youpi> no idea, I don't even know what that is suppsoed to do
<youpi> it's probably something like tiocsctty, but I don't really know
<gnu_srs> Redirecting console output to a pseudotty
<youpi> omg that ioctl is so ugly
<youpi> the way I can see it working is to add an RPC to the /dev/console
translator (i.e. /hurd/term) to give it the fd, and have /hurd/term write
to it whenever it gets writes, instead of writing to the console device
<youpi> gnu_srs: what do you need that for?
<gnu_srs> bootlogd in sysvinit use that for logging.
<gnu_srs> should I propose a patch to avoid the segfault when booting then?
<youpi> at least, yes
<youpi> *bsd will need it anyway
<gnu_srs> youpi: btw: hurd console does not work when running openrc,
neither is halt/reboot. Maybe you should try it out?
<gnu_srs> bootlogd use ioctl(0, TIOCCONS, NULL) a Linux (only) construct
<gnu_srs> ?
<youpi> gnu_srs: I had infinite time in the day, I would be able to try it
out, yes
<braunr> heh
<youpi> giving NULL to TIOCCONS is a linux-only construct, yes
<youpi> to be compatible with *BSD, you have to pass the parameter
mentioned above
<youpi> instead of NULL
<gnu_srs> well bootlogd is from sysvinit, so it is a matter if we move to
that for init.
<gnu_srs> ***checking if bootlogd segfaults on kFreeBSD too
# Non-constant structures as IOCTL parameter
[[!debbug 413734]].
## IRC, OFTC, #debian-hurd, 2014-02-16
<gg0> https://bugs.debian.org/413734
<gg0> patch #2 has become http://paste.debian.net/plain/82412/
<gg0> ie. almost entirely ifdef'ing DeviceEnum
<gg0> ok final patch is http://paste.debian.net/plain/82440/
<gg0> could anyone review it, especially last 3 oss hunks?
<azeem> gg0: well probably it would be cleaner to have autoconf check for
any of the three soundcard.h include locations?
<gg0> azeem: i think if upstream is ok with 2 it could be ok with 3 too
<gg0> my concern is about linux/ in header path (hurd is not linux) and
about ways cleaner than last 2 hunks
<azeem> well yeah, #ifdef __GNU__ #include <linux/foo.h> certainly looks
ugly
<gg0> i'll ifdef ioctls only
### IRC, OFTC, #debian-hurd, 2014-02-17
<gg0> http://paste.debian.net/plain/82446/
<gg0> https://trac.videolan.org/vlc/ticket/10696
### IRC, freenode, #hurd, 2014-02-17
<gg0> porting vlc with http://paste.debian.net/plain/82446/ +
http://paste.debian.net/plain/82510/
<gg0> what's the proper way to fix ioctl instead of ifdef'ing them?
<gg0> see https://bugs.debian.org/413734
<braunr> gg0: defining them in libc
<braunr> and in servers implementing them ofc
|
