IRC channel 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>ok

<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>s/rtentry/srtentry/

<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>};

<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

<damo22>ok

<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

<damo22>ok

<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>1

<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 255.255.255.255 as the destination address, i think there is a bug in our stack that means you need the broadcast route

<youpi>possibly

<youpi>how was it working previously?

<damo22>im trying to figure that oiut

<youpi>255.255.255.255 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 = 0.0.0.0

<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

<damo22>??

<youpi>perhaps you *really* need to read about tcp/ip networking configuration

<damo22>right

<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>yes

<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 = 0.0.0.0

<damo22>so that dhcp can work on address 255.255.255.255

<youpi>again, there is no reason why the network stack would require any route to get packets emitted to 255.255.255.255

<youpi>255.255.255.255 basically just means "send that out"

<damo22>see README in isc-dhcp-client

<damo22>we are on old linux stack

<youpi>bleh

<damo22>i dont know how it currently works with dst=0.0.0.0 because i need to use dst=255.255.255.255

<youpi>if you have a route for dst=0.0.0.0/0, you can send to 255.255.255.255 since that's inside 0.0.0.0/0

<damo22>so i need mask = 255.255.255.255 ?

<damo22>and dst = 0.0.0.0.

<youpi>??

<youpi> /0 is mask 0.0.0.0

<youpi>REALLY

<youpi>please read anout tcp/ip

<youpi>if you don't understand cidr and netmask we cant understand each other

<damo22>ok

<damo22>i think my code is borked because i special cased 0.0.0.0 and 255.255.255.255 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 0.0.0.0/0 route

<gnucode>hello hurd!

IRC channel logs

2022-08-29.log