IRC channel logs


back to list of logs

<Pellescours>youpi: in libstore I have the file_write that takes amount: size_t and it calls io_write that takes amount: vm_size_t
<Pellescours>what should I do? change all libstore interfaces?
<youpi>I'd say so, yes :/
<Pellescours>TT let’s go
<Pellescours>youpi: gcc says there is a use after free here (libpipe/pq.c:209), I can’t manage it as i’m already on type fixes
<Pellescours>same for proc/info.c:952
<youpi>it's actually a false positive
<youpi>we use the pointer in arithmetics only
<youpi>it can be cleaned by doing the subtraction before the realloc and store it in a temporary variable, but that's really only about shutting down the warning, there's no real bug here
<youpi>so patch welcome, but that's really not a priority :)
<Pellescours>I fixed all errors, now I have a lot of incompatible-pointer-types, so a lot of interfaces to changes
<Pellescours>time to sleep, good night
<Pellescours>I’ll try to have a patch tomorrow
<youpi>Mmmm, looking at io_read...
<youpi>out data:data_t
<youpi>that's thus using a mach_msg_type_number_t
<youpi>while the size is vm_size_t
<youpi>possibly we'd rather make mig use longs for mach_msg_type_number_t
<youpi>(which doesn't mean we shouldn't fix the types)
<damo22>\o/ libacpica is in the repo
<damo22>it seems ACPI is supposed to handle SCI interrupts on irq9
<damo22>for now i have bypassed the registration of the handler
<damo22>youpi: i dont understand how ifnam is passed to the ioctl, if its not part of the struct that is passed to the ioctl
<damo22>i mean, its implemented as a separate struct
<damo22>its like this for other ioctls
<damo22>the IOT is a separate definition than the struct itself
<damo22>am i supposed to modify the struct rtentry to include ifnam_t at the beginning?
<damo22>for userland to pass in the ifnam as well
<damo22>the routine () has ifnam_t then the struct after that... how does that even work?
<damo22>for example, if the IOT should be: #define _IOT_srtentry _IOT (_IOTS(char), IFNAMSIZ, _IOTS(int), 3, _IOTS(short int), 2)
<damo22>and the struct is:
<damo22>struct srtentry {
<damo22> in_addr_t rt_dest;
<damo22> in_addr_t rt_mask;
<damo22> in_addr_t rt_gateway;
<damo22> unsigned short int rt_flags;
<damo22> unsigned short int rt_mtu;
<damo22>how does the ifnam get prepended to the struct that is passed from ioctl?
<damo22>do i create a superset struct that has both structs in it?
<damo22>and pass that to the ioctl?
<biblio>damo22: some steps how to test your code README (after installing or download hurd-***.img) would be nice. I am not clear how can I test your code :(
<damo22>which one
<biblio>damo22: routing one
<damo22>its work in progress, i submitted the patch but its not ready yet
<damo22>did you see the followup
<damo22>on the ml
<biblio>damo22: no. I think I missed that.
<biblio>damo22: I will check that. thanks
<damo22>im actually working on it righ tnow
<biblio>damo22: Ok sure. let me know when can I test it...
<youpi>damo22: the rpc doesn't care if it's passed in the structure or not, it just packs data, and unpacks it
<youpi>yes, add ifnam in the srtentry, it's in the rtentry (as a char*)
<damo22>but to be consistent with the other ioctls, shouldnt we keep them as two structs?
<youpi>no need for it
<youpi>I mean on the client side
<youpi>on the server side you can keep it as separate parameters
<youpi>really, just like SIOCSIFADDR
<damo22>well that example has two structs embedded in the struct ifreq
<damo22>like i was suggesting
<damo22>so i can create struct ifrtreq
<damo22>that puts the ifname then the struct srtentry into one struct
<damo22>i was trying to make the server and client use the same definition
<youpi>it's not two structs
<youpi>it's two unions
<youpi>it's like that *only* because ifreq is for several kinds of requests
<youpi>actually the first union is completley useless since there's only one alternative
<youpi>there is no need to make the server and client use the same definition
<damo22>ok but i dont want two structs created, one for server and one for client, with the same names, but different structure
<youpi>right, that does make sense
<damo22>so i was thinking to call the server one: ifrtreq
<youpi>now, that being said, see what I wrote on the list: better add the other usual fields (metric, etc.) in the structure, as ints (and make flags and mtu ints as well, so it can fit the ioctl)
<damo22>interface route request
<damo22>yes i saw your mail, i will add the extra fields too
<damo22>wait, the IOT is the client side?
<damo22>ok i will call the client side struct ifrtreq
<youpi>the IOT is both the client side and the RPC packing
<damo22>youpi: what fd do i use to send a ioctl to the network card?
<damo22>skfd = socket (AF_INET, SOCK_DGRAM, 0); ?
<youpi>I'd say look how inetutils-ifconfig does it
<damo22>why is it useless to add a broadcast route? it does not work otherwise
<youpi>because you don't at all need that
<youpi>provided that you have the route for the local network
<damo22>but dhclient uses as the destination address, i think there is a bug in our stack that means you need the broadcast route
<youpi>how was it working previously?
<damo22>im trying to figure that oiut
<youpi> should be always working actually
<youpi>it doesn't need a route
<youpi>it just means "send that out to the network"
<youpi>which is differnet from the broadcast address for the local network, which does need the local network route to be configured
<damo22>yeah but our stack doesnt understand all addresses by default
<damo22>it needs an initial bootstrapping route that lets it send packets
<youpi>"our stack" is just the linux tcp/ip stack
<youpi>I don't think it needs anything particular
<youpi>but of course it's the source code that will tell what it does now
<youpi>I'm just telling what it should be shaped into
<damo22>it currently sets a route with dst =
<damo22>(after setting default gw)
<youpi>which default gw?
<damo22>the one provided on cli
<damo22>rta.rta_gw = &gw4_in->gateway;
<youpi>when using dhcp you don't set a gateway on the cli
<damo22>but we are setting it with -g
<youpi>that's the whole point of using dhcp
<youpi>you don't need to
<youpi>perhaps you *really* need to read about tcp/ip networking configuration
<damo22>i understand
<youpi>it seems you 're completely lost
<damo22>but pfinet is being called with params
<youpi>not necessarily
<damo22> if (in->gateway != INADDR_NONE)
<damo22> gw4_in = in;
<youpi>setup-translators doesn't set up any parameter
<youpi>yes but that's only if the user configures that by hand
<youpi>nobody does that, actually
<damo22>so it only sets this route if the param is set by hand
<youpi>which is expected
<damo22>yes but if there is no gateway passed, and you are using dhcp, you still need a special route with dst =
<damo22>so that dhcp can work on address
<youpi>again, there is no reason why the network stack would require any route to get packets emitted to
<youpi> basically just means "send that out"
<damo22>see README in isc-dhcp-client
<damo22>we are on old linux stack
<damo22>i dont know how it currently works with dst= because i need to use dst=
<youpi>if you have a route for dst=, you can send to since that's inside
<damo22>so i need mask = ?
<damo22>and dst =
<youpi> /0 is mask
<youpi>please read anout tcp/ip
<youpi>if you don't understand cidr and netmask we cant understand each other
<damo22>i think my code is borked because i special cased and as always being /32
<damo22>if nobody needs to route to global broadcast address, why not use it as a /32 for dhcp only
<damo22>ok i have replicated the current behaviour with a route
<gnucode>hello hurd!