IRC channel logs
2022-08-31.log
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 <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>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>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 <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. <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 <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 <youpi>bsd used to have the SIOCADDRT <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? <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>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 192.168.1.0 255.255.255.0 <damo22>its trying to call the SIOCADDRT ioctl <damo22>32 err = ioctl(skfd, SIOCADDRT, &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>do i pass a pointer to the structure in the ioctl? <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? <damo22>ioctl_handler_t handler = _hurd_lookup_ioctl_handler (request); <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>328 return __hurd_fail (MIG_TYPE_ERROR); <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>look at what ifs lead to that return <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 <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>$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 <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> const mach_msg_type_t routeCheck = { <damo22> /* msgt_name = */ (unsigned char) MACH_MSG_TYPE_CHAR, <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>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