From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 26 Feb 2014 12:32:06 +0100 Subject: IRC. --- open_issues/glibc_ioctls.mdwn | 103 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 101 insertions(+), 2 deletions(-) (limited to 'open_issues/glibc_ioctls.mdwn') diff --git a/open_issues/glibc_ioctls.mdwn b/open_issues/glibc_ioctls.mdwn index 14329d0f..3f396754 100644 --- a/open_issues/glibc_ioctls.mdwn +++ b/open_issues/glibc_ioctls.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!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 @@ -10,7 +10,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_glibc]] -IRC, unknown channel, unknown date. + +# 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 @@ -70,3 +71,101 @@ IRC, unknown channel, unknown date. right which might end up in mach, other processes, other machines, etc. * pinotree s/Mach/Hurd/ :) + + +# `TIOCCONS` + +## IRC, freenode, #hurd, 2014-02-05 + + Hi, anybody have time to look at what fails with: ioctl(0, + TIOCCONS, NULL)? + found a program doing the same function call as bootlogd: + http://paste.debian.net/80231/ + rpctrace: http://paste.debian.net/80232/ + gnu_srs: it seems there is a misunderstanding between linux and + *bsd on this one + 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 + see + http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022116.html + for the bsd implementation, for instance + youpi: replacing 0 with &i where int i=1 gives: TIOCCONS: + Inappropriate ioctl for device + so be it, but that's clearly needed to be able to work on bsd + and probably the implementation is just missing on the Hurd for now + jus to be clear: do you mean 0 or NULL in: ioctl(0, TIOCCONS, + NULL)? + yes, for instance there is an implementation do_tiocsctty in glibc, + but no to_tioccons + I mean NULL + OK, that's where I changed, the first argument id the FD + well, when I wrote "NULL", I really meant "NULL" ... + yes sure, so you say that it is not yet implemented? + yes, for instance there is an implementation do_tiocsctty in glibc, + but no to_tioccons + easy to do? + no idea, I don't even know what that is suppsoed to do + it's probably something like tiocsctty, but I don't really know + Redirecting console output to a pseudotty + omg that ioctl is so ugly + 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 + gnu_srs: what do you need that for? + bootlogd in sysvinit use that for logging. + should I propose a patch to avoid the segfault when booting then? + at least, yes + *bsd will need it anyway + youpi: btw: hurd console does not work when running openrc, + neither is halt/reboot. Maybe you should try it out? + bootlogd use ioctl(0, TIOCCONS, NULL) a Linux (only) construct + ? + gnu_srs: I had infinite time in the day, I would be able to try it + out, yes + heh + giving NULL to TIOCCONS is a linux-only construct, yes + to be compatible with *BSD, you have to pass the parameter + mentioned above + instead of NULL + well bootlogd is from sysvinit, so it is a matter if we move to + that for init. + ***checking if bootlogd segfaults on kFreeBSD too + + +# Non-constant structures as IOCTL parameter + +[[!debbug 413734]]. + + +## IRC, OFTC, #debian-hurd, 2014-02-16 + + https://bugs.debian.org/413734 + patch #2 has become http://paste.debian.net/plain/82412/ + ie. almost entirely ifdef'ing DeviceEnum + ok final patch is http://paste.debian.net/plain/82440/ + could anyone review it, especially last 3 oss hunks? + gg0: well probably it would be cleaner to have autoconf check for + any of the three soundcard.h include locations? + azeem: i think if upstream is ok with 2 it could be ok with 3 too + my concern is about linux/ in header path (hurd is not linux) and + about ways cleaner than last 2 hunks + well yeah, #ifdef __GNU__ #include certainly looks + ugly + i'll ifdef ioctls only + + +### IRC, OFTC, #debian-hurd, 2014-02-17 + + http://paste.debian.net/plain/82446/ + https://trac.videolan.org/vlc/ticket/10696 + + +### IRC, freenode, #hurd, 2014-02-17 + + porting vlc with http://paste.debian.net/plain/82446/ + + http://paste.debian.net/plain/82510/ + what's the proper way to fix ioctl instead of ifdef'ing them? + see https://bugs.debian.org/413734 + gg0: defining them in libc + and in servers implementing them ofc -- cgit v1.2.3