rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 171 deletions

diff --git a/open_issues/glibc_ioctls.mdwn b/open_issues/glibc_ioctls.mdwn
deleted file mode 100644
index 3f396754..00000000
--- a/open_issues/glibc_ioctls.mdwn
+++ /dev/null
@@ -1,171 +0,0 @@
-[[!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