***jrtc27_ is now known as jrtc27
***nckx_ is now known as nckx
<biblio>demo22: youpi: I was able to fix build error of libmnl but could not make deb package yet. getting - dpkg-genbuildinfo: error: binary build with no binary artifacts found; .buildinfo is meaningless <damo22>biblio: how are you compiling the deb pacakge <biblio>damo22: dpkg-buildpackage -us -uc <damo22>did you clone from salsa.debian.org <biblio>damo22: no I got it from apt-get source libmnl <biblio>damo22: I also tried by add CPPFLAGS in debian/rules - still could not make it work <youpi>biblio: netfilter is linux-only, libmnl won't ever work on the hurd <youpi>that said it's odd that you don't get an arch:any package built <biblio>youpi: oh. i saw it is a required package for iproute2 and iproute2 is marked as TODO. <biblio>youpi: ok i will check other packages from TODO. thanks for the info. <damo22>im guessing there is something missing in netdde for the translator to accept a route entry? <youpi>again, netdde only contains drivers <youpi>it's pfinet that contains the tcp/ip stack <damo22>what uses servers/socket/* to manipulate pfinet stack? <youpi>or you mean to configure it? <youpi>inetutils-ifoncifg and friends <biblio>youpi: I could not find any package in inetutils for adding routes. <biblio>youpi: it would be nice they inetutils provides inetutils-route or something similar. <youpi>it's a matter of contributing it <damo22>i found ifconfig inside that package with hurd support but it seems turned off <damo22>how? it does not install on my system <youpi>it does on my and freshboxes <biblio>damo22: just install inetutils-tools <damo22>root@zamhurd:~# apt install inetutils-ifconfig <damo22>E: Unable to locate package inetutils-ifconfig <damo22>root@zamhurd:~# apt install inetutils-tools <damo22>inetutils-tools is already the newest version (2:2.3-4). <damo22>biblio: ioctl(skfd, SIOCADDRT, &rt) <damo22>or deleting a route ioctl(skfd, SIOCDELRT, &rt) <damo22>just need to populate the rt with the right data <damo22>i cant find the definition for the struct rtentry <damo22>#define CONFIG_IP_NOSIOCRT 1 /* How convenient. */ in pfinet config.h <damo22>so hurd's pfinet has no ioctl for setting routes? <youpi>I guess just nobody took the time to look at it <damo22>biblio: see hurd-debian/pfinet/linux-src/net/ipv4 <biblio>damo22: i am looking in my /user/include which location you is your hurd-debian ? <damo22>biblio: i mean the debian "hurd" package <biblio>damo22: could you share the location of the file. I got bit confused now :( <damo22>i am going to try rebuilding pfinet with that undeffed <damo22>ok it fails due to missing SIOCxxxRT definitions <gnu_srs1>damo22: biblio: Isn't it more interesting to replace pfinet with lwip? <damo22>there is no reason to keep it broken <damo22>if i was going to replace pfinet i would use rumpnet <gnu_srs1>I assumed lwip is the future since pfinet contains Linux code? <biblio>gnu_srs1: I am new to lwip. thanks for mentioning. <damo22>im building pfinet having SIOCADDRT <damo22>/usr/bin/ld: fib_frontend.o: in function `ip_rt_ioctl': <damo22>./build-udeb/pfinet/../../pfinet/linux-src/net/ipv4/fib_frontend.c:263: undefined reference to `rtnl_lock' <damo22>/usr/bin/ld: ./build-udeb/pfinet/../../pfinet/linux-src/net/ipv4/fib_frontend.c:280: undefined reference to `rtnl_unlock' <damo22>maybe i can define those as macros with noops <biblio>damo22: it would be also possible $ apt-cache search linux | grep headers <biblio>damo22: install # apt-get install linux-headers-5..xx-common in hurd. and then you can check the actual value in latest kernel. I am not sure if it will be best way to do it. Just an idea. <damo22>its turned off behind that #define <damo22>but im not sure how the ioctl gets hooked up <damo22>i think i made it compile and link with the existing code <damo22>which means we can call ip_rt_ioctl somehow ***valerius- is now known as valeriusN
<damo22>youpi: i invented two separate ioctls for "default gw" and "static" routing <damo22>SIOCADDRT is supposed to do both <damo22>it was easier to just write two separate functions <youpi>the structure parameter of SIOCADDRT allows to know between the two, doesn't it? <damo22>yea but it needs a huge structure <damo22>actually i cant find the structure it wants <damo22>but iioctl server has them defined for all other ones <youpi>isn't it what ip_rt_ioctl manages? <damo22>we are not using the linux ioctls, <damo22>i need to add something to iioctl.defs <damo22>iioctl-ops.c:S_iioctl_siocaddrt_def_gw (struct sock_user *user, <damo22>iioctl-ops.c:S_iioctl_siocaddrt_static (struct sock_user *user, <damo22>iioctl-ops.c:S_iioctl_siocdelrt_def_gw (struct sock_user *user, <damo22>iioctl-ops.c:S_iioctl_siocdelrt_static (struct sock_user *user, <damo22>unless i just pass a flag to it to choose <damo22>there is no point reusing the old structure for the ioctl surely, it just needs an address and an ifnam and a sock_user, and a flag that says if its a default gw or static route? <damo22>ok, i think i can handle this, but what number are the two ioctls SIOCADDRT and SIOCDELRT? <youpi>it's computed automatically from the structure content by the _IOR/W macros <damo22>ok but there are skips in the iioctl.defs file, i dont want to use a ioctl that has a different meaning just by throwing it on the end? <youpi>the numbering is following the bsd numbers <youpi>see SIOCSIFADDR etc. in there <damo22>can pfinet options.c call iioctl_U.h ? <damo22>or is that making a rpc to itself? <damo22>i want to deduplicate the routing code from options.c <youpi>? pfinet is not supposed to make ioctl calls <youpi>it's glibc on the client side, where ioctl is turned into an iioctl RPC <youpi>that calls into an iioctl on the server side <youpi>ending up in S_iioctl_* function call, e.g. in pfinet <damo22>ok so pfinet has to set up routes etc which is exactly the code in S_iioctl_siocaddrt <damo22>do i break it out into a function so pfinet internals can call it? <damo22>i implemented S_iioctl_siocaddrt from scratch <damo22>but it needs to be also called from options.c <damo22>as well as being a server implementation <youpi>then create a function that can be called both from S_iioctl_siocaddrt and from options.c ? <damo22>it still works! and i refactored options.c <damo22>hmm how do i generate iioctl_U.h ? <damo22>what needs to call the iioctl? glibc? <youpi>damo22: I don't understand where you got that iioctl_U.h name from <youpi>to call an iioctl, you just have to call the ioctl <youpi>ioctl() in the glibc happens to turn that into an iioctl call, as I mentioned above <Pellesco1rs>damo22: can you remember what need to be done with rump to use the rump ide driver instead of the linux one? I remember a discussion about Makefile to separate something into 2 distincts libs <damo22>currently the symbols are included twice from cd and wd because they are compiled into both <damo22>they need to be separated into separate libs so we can link them as needed <Pellesco1rs>so introduce a 3rd lib that ide and ahci will link to, right? <Pellesco1rs>and to run the piixide rump driver, rumpdisk can be modified to use it and expose the cd devices? <damo22>it only needs to link to the right libs, it will detect the ide card <damo22>in theory we can compile in both libs ***Pellesco1rs is now known as Pellescours