IRC channel logs


back to list of logs

***Server sets mode: +nt
<damo22>Pellescours: if ata needs to be included only once when you link the libs, then ata must be a separate library, libata.a
<damo22>or whatever its called
<biblio>damo22: youpi: minor fixes: and (Is there any way to send these patches without using git hub ?)
<youpi>you have to use what upstream expects. I don't see kconfig being on github but on
<youpi>The qWait addition looks odd, it looks like browntape, I don't think upsteram will like that
<youpi>but at least the extra-cmake-modules change can be submitted as-is, and various packages be fixed into using it
<youpi>there are a lot of them referenced in graph-top.txt
<youpi>just looking for "Your current platform 'GNU' is not supported. The list of supported" will give you the list :)
<biblio>youpi: yes. it is getting supported list from metainfo.yaml
<biblio>youpi: withou QTest::qWait 1 test is failing (crashing) randomly because tests are running too fast for Hurd VM. I used gdb but not an error.
<youpi>how is that "too fast"
<youpi>I mean, it's usually a good thing that something goes fast :)
<biblio>youpi: one is is failing randomly no logical explanation for failure.
<youpi>if something expects that it's longer, there's probably a good reason, and sleeping is not the proper way to fix it
<youpi>there surely is a logical explanation
<damo22>Routing Table:
<damo22>Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT
<damo22>/dev/eth0 0002000A 00000000 0001 0 0 0 00FFFFFF 0 0 0
<damo22>/dev/eth0 00000000 0202000A 0003 0 0 0 00000000 0 0 0
<damo22>/dev/eth0 00000000 00000000 0001 0 0 0 00000000 0 0 0
<youpi>great ):
<damo22>it prints that at startup but i dont know how to make it expose on a node
<youpi>biblio: that being said, you can as well submit the cmake part, and we can run kconfig in debian with nocheck
<biblio>youpi: Yes I agree. But so far no luck with gdb with debug build. No error message nothing. Just randomly one of the kconfigcompiler_test.cpp test is failing.
<biblio>youpi: ok thats another option
<youpi>damo22: maybe you could rather add it to /proc as people will expect, making proc run an RPC to get the table from pfinet
<biblio>damo22: :)
<biblio>youpi: ok
<damo22>oh good idea
<damo22>it does not need to be an ioctl, just a rpc from pfinet?
<damo22>there is no ioctl definition for getting routes in bsd even
<damo22>i think?
<youpi>bsd used to have the SIOCADDRT
<youpi>it can be a mere rpc yes
<damo22>addrt is just to add routes, i dont think you can get them too?
<youpi>ah, for getting routes, I don't know
<damo22>if i make it exposed on /proc/net/route, does that mean existing linux route tool should work
<damo22>maybe we could move to net-utils?
<damo22>or is it net-tools
<jlledom>hi guys, got some questions, why are there two files called ds_routines.c, one in gnumach and the other one in libmachdev, that define the same functions? what's the relation between them?, what's libmacdev for?
<Pellescours>jlledom: i would says because libmachdev is the lib to interract with the kernel (gnumach). So one is for kernelland and the other is for userland
<damo22>libmachdev is a userland implementation of the mach device interface
<damo22>so we can have mach devices entirely in userland that appear like gnumach devices
<damo22>youpi: why do we have S_pfinet_siocgifconf with an optional parameter for amount of data to read?
<damo22>why does it matter?
<damo22>i mean in general, if you dont know how big the buffer will be in advance, why cant you just dynamically allocate it always in the server side?
<damo22>is this so you dont have to free it, you can allocate things on the stack and throw it away after?
<jlledom>Pellescours: damo22: thanks I understand
<youpi>damo22: I don't know why that amount parameter was added to siocgifconf, probably just because the bsd/linuxish struct ifconf has it
<damo22>youpi: $ sudo ./test
<damo22>BAD 1! errno=-304
<damo22>its trying to call the SIOCADDRT ioctl
<damo22>32 err = ioctl(skfd, SIOCADDRT, &route);
<damo22>(gdb) p route
<damo22>$1 = {ifname = "/dev/eth0\000\000\000\000\000\000", rt_dest = 108736, rt_mask = 16777215, rt_gateway = 0,
<damo22> rt_flags = 0, rt_metric = 0, rt_mtu = 0, rt_window = 0, rt_irtt = 0, rt_tos = 0, rt_class = 0}
<damo22>do i need to recompile glibc with the new net/route.h?
<youpi>note that -304 is EMIG_BAD_ARGUMENTS, so it's not the content of the data, but the shape, that wasn't recognize
<youpi>perhaps step-by-step inside ioctl() to check that it's understanding what you want correctly
<youpi>IIRC the glibc build doesn't do anything particular, everything is encoded by the IOT macro
<damo22>i have /proc/route working
<damo22>do i pass a pointer to the structure in the ioctl?
<youpi>that's how ioctls work yes
<damo22>the client side must pass the device name right? otherwise how would the ioctl know which device to address?
<youpi>the device name is in the structure
<damo22>is 56 bytes too long for an ioctl?
<youpi>the constraints are just the IOT encoding
<youpi>really, step-by-step inside ioctl() to see how it's working
<damo22>how do i get debug symbols in ioctl?
<youpi>libc0.3-dbg ?
<damo22>ioctl_handler_t handler = _hurd_lookup_ioctl_handler (request);
<damo22>is returning 0
<youpi>that's for registered special ioctls
<youpi>that's probably not what you're after
<youpi>it's the way for glibc for handling some ioctls itself
<youpi>when it's not for the server to handle it
<youpi>(or because the hurdish rpc is different)
<damo22>request is 0x8882818A
<damo22>328 return __hurd_fail (MIG_TYPE_ERROR);
<damo22>(gdb) x/16c arg
<damo22>0x1039d54: 47 '/' 100 'd' 101 'e' 118 'v' 47 '/' 101 'e' 116 't' 104 'h'
<damo22>0x1039d5c: 48 '0' 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0 '\000'
<youpi>again, it's not the content that matters here
<youpi>but the sizes
<youpi>look at what ifs lead to that return
<damo22>(gdb) p m->msgh_size
<damo22>$16 = 1
<damo22>(gdb) p reply_size
<damo22>$17 = 32
<damo22>(_IOC_INOUT (request) & IOC_OUT) <--- should that be IOC_IN ?
<damo22> IOC_OUT = 1, /* Data is written into the user's buffer. */
<damo22> IOC_IN = 2, /* Data is read from the user's buffer. */
<youpi>for ADD/DEL RT you don't need to get data back
<youpi>so IN only
<damo22>yes i am using _IOW which is #define _IOW(g, n, t) _IOC (IOC_IN, (g), (n), _IOC_ENCODE_TYPE (t))
<damo22>but the glibc code is only checking IO_OUT
<damo22>and the message size has to match the reply
<damo22>why does (m->msgh_size need to match reply_size)?
<youpi>because otherwise it means it's incoherent, i.e. a bug, and thus better error out than silently be happy about it
<youpi>it's normal that it's only checking the OUT part
<youpi>for the IN part there's no coherency to check since it's glibc itself that builds the msg
<damo22>(gdb) p *t
<damo22>$28 = {msgt_name = 47, msgt_size = 101, msgt_number = 2164, msgt_inline = 0, msgt_longform = 1,
<damo22> msgt_deallocate = 1, msgt_unused = 0}
<damo22>$29 = {{header = {Head = {msgh_bits = 4608, msgh_size = 32, msgh_remote_port = 0, {msgh_local_port = 60,
<damo22> msgh_protected_payload = 60}, msgh_seqno = 30, msgh_id = 112110}, RetCodeType = {msgt_name = 2,
<damo22> msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0,
<damo22> msgt_unused = 0}, RetCode = -304}, header_typecheck = {Head = {msgh_bits = 4608, msgh_size = 32,
<damo22> msgh_remote_port = 0, {msgh_local_port = 60, msgh_protected_payload = 60}, msgh_seqno = 30,
<damo22> msgh_id = 112110}, RetCodeType = 268509186, RetCode = -304}}, data = 0x1039c20 "/eth0"}
<damo22>the data chewed up the first four bytes of "/dev"
<youpi>what are you printing and when?
<youpi>otherwise I can have no idea what it's supposed to be
<youpi>whatever is printed can very well be just a remnant on the stack
<youpi>also, did you determine whether the -304 actually comes from ioctl.c, or from the server?
<damo22>Thread 4 hit Breakpoint 4, __GI___ioctl (fd=<optimized out>, request=<optimized out>)
<damo22> at ../sysdeps/mach/hurd/ioctl.c:292
<damo22>292 switch (err)
<damo22>(gdb) p *msg
<youpi>and what is err?.
<damo22>(gdb) p err
<damo22>$33 = EMIG_BAD_ARGUMENTS
<youpi>so it's not ioctl.c that produces it, no need to look at it
<damo22>the iioctl server is returning that?
<youpi>apparently , since err is coming from the msg() function
<youpi>or the RetCode of the message
<youpi>as apparently printed by gdb
<damo22>it has a TypeCheck
<damo22>and its failing for some reason
<damo22> const mach_msg_type_t routeCheck = {
<damo22> /* msgt_name = */ (unsigned char) MACH_MSG_TYPE_CHAR,
<damo22> /* msgt_size = */ 8,
<damo22> /* msgt_number = */ 40,
<damo22>its the right size overall, but shouldnt it be an int type (32) with 10 of them?
<damo22>ohh, srtentry array of char[40] or whatever
<damo22>type srtentry_t = struct[10] of int;
<damo22>i inserted a route
<damo22>and confirmed with /proc/rout
<damo22>youpi: it only prints it to pfinet's stdout, not to the console
<damo22>you dont see it unless you run the network stack yourself
<damo22>pfinet prints other information too
<damo22>i mean, i can remove that printing but the rest of the commit is needed