<Pellescours>I’m trying to build hurd (without debian patches) and it fails to build libtrivfs <Pellescours>it says : /libtrivfs/startup.c:154:17: error: ‘SIGTERM’ undeclared <Pellescours>now, I’m trying to make rumpdisk being build with piixide and ahcisata <damo22>youpi: do i need to patch glibc in some way to add the ioctl apart from the header? i am getting seg fault on ioctl as if it does not exist <Pellescours>damo22: I try to make atapi a separate lib but for now I’m failing and I don’t know If what I’m trying to do is the good way <youpi>damo22: you just need to #define the SIOC <youpi>and rebuild glibc against the new iioctl.defs file <youpi>Mmm, actually you may not even need that on the client side, probably only the server side <damo22>i am confused about dest, gw, and mask. Are these all required to add a static route and/or a gateway? <damo22>0.0.0.0 is the dst for a default gw? <youpi>you need to know the destination+mask, and the gateway to go through <youpi>0.0.0.0/0 would be "all destination" <damo22>the mask is not being set in the current code <damo22>actually i dont know how to set the mask at all <youpi>well, it's just the netmask corresponding to the cidr prefix length <damo22>there is code in there that adds default gw <damo22>but how does it work without setting the mask 255.255.255.0? <youpi>I see it set in trivfs_append_args <damo22>that just adds the argument "gateway" <youpi>there's also netmask management <damo22>ahh its set via configure_device? <damo22>so you can only have one netmask per device? <damo22>ok, then what im saying is i cannot find a way to set the netmask per route <youpi>I don't think options.c currently supports having more than just the default route <youpi>and the route for the network of the only IP of the device <damo22>it gives lots of hints how to use the fib interface <damo22>its basically a linked list of routes that get inserted i think <damo22>the problem is, kern_rta has no element for mash <damo22>so i dont know how to set it per route <damo22>you need to compute the length of the mask and set that <damo22>youpi: is the IOT_COUNT* in bytes or number of elemens? <youpi>number of elements I guess, it'd be wasteful otherwise <damo22>$1 = {rt_dest = 257, rt_mask = 4294967295, rt_gateway = 0, rt_flags = 2, rt_mtu = 0} <damo22>$2 = {rt_dest = 0, rt_mask = 16777215, rt_gateway = 0, rt_flags = 4, rt_mtu = 0} <damo22>are these the correct routes for default gateway and dhcp setup? <youpi>it's supposed to be all-ones starting from most significant bits <youpi>4294967295 would be a one-IP route, i.e. a /32 <damo22>so the first one should be mask=0? <youpi>I don't even know what is supposed to be what <youpi>also, rt_gateway being always 0 looks just plain wrong <damo22>its in order of the options.c routing, first it adds the gateway, then adds the dhcp route <damo22>i am passing the wrong parameters thats for sure <damo22>youpi: now i get dhcp broadcast to 255.255.255.255 failing <damo22>i dont understand what the two routes are for, one is to set up the gateway, and the other one is something to allow packets to flow? <damo22>entry0: dest=anywhere with mask=mask -> gateway=gateway <damo22>DHCPDISCOVER on /dev/eth0 to 255.255.255.255 port 67 interval 10 <damo22>send_packet: Network is unreachable <damo22>send_packet: please consult README file regarding broadcast address. <damo22>dhclient.c:2460: Failed to send 300 byte long packet over /dev/eth0 interface. <damo22>hmm do i need to set src address too <damo22>It is possible to work around this problem on some versions of Linux <damo22>by creating a host route from your network interface address to <damo22>youpi: i got #define EMIG_BAD_ARGUMENTS -304 <damo22>hmm how do i test a second subnet being routed? i dont have another machine attached with different subnet <damo22>youpi: there is no ioctl to get the routing table... should that be exposed as a file on /servers/sockets/routes ? <damo22>biblio: did you see my latest patch? it allows you to set/delete routes, but there is no way to see what routes are loaded per device <biblio>damo22: i will check. Is it in your git repo ? <biblio>damo22: ok I will check and let you know :) <damo22>but in the commit message there is a change required to glibc <damo22>i am yet to try compiling it and testing the full route loading <damo22>but the default routes still work <biblio>damo22: ok. best way to test would be adding two ethernet card and set a rule for a a specific ip to use use one of them <biblio>damo22: later check with iptraf tool. not sure if it is in hurd. <damo22>youpi: i remember now why i cant put everything into acgnuex.h, its because that file is auto included in *every* source file within acpi <damo22>so i cant put the implementation of the hooks in there <youpi>damo22: (EINVAL) it's not a macro, in hurd it's an enu <youpi>damo22: the other route is for packets to the local network <youpi>reading a bit about basic tcpip would help :) <youpi>entry0 should have mask 0, since it's all addresses <youpi>and entry1 should have the same mask as the device's ip, since that's for the ips of the local network (and no need for a gateway, thus) <youpi>entry1 is needed for the stack to be able to send packets to the gateway... <youpi>you don't need to set a src address <youpi>you can test different subnets by telling qemu to use a tap device, and run two vms on ti <youpi>for exposing routes, a translator file woudl be useful yes <youpi>"so i cant put the implementation of the hooks in there" sure you can, as static inlines <youpi>since the functions are very trivial that's not a concern <youpi>for non-trivial functions you can create a file, yes <youpi>only os_map_memory, register_slot, get_irq_number, and acpi_init really deserve being in the file <youpi>all the other ones will be very trivial once inlined <damo22>ok shall i refactor the functions as inlines before adding to master libacpica? <damo22>i read that static inline means they all get a new copy of the inline function, but we only need to define it once <youpi>static inline are optimized away when they're not used <damo22>ok, problem is i need to #include <acpi/acpi.h> and that does not work inside acgnuex.h <damo22>i tested by statically linking it to a main and calling acpi_init <youpi>Just some nit picks: in acpi_os_get_timer, you have to cast tv_sec into u64 before multiplying, otherwise it' overflow, Also, put write_port next to read_port. (there's no write_iomem?) <damo22>-rwxr-xr-x 1 demo demo 5548 Aug 28 22:04 testacpi <damo22>-rwxr-xr-x 1 demo demo 1705916 Aug 28 22:04 testacpi.static <youpi>damo22: note that you can use lintian on the .changes file to tell you bugs ni the packaging <youpi>it'll probably be better to fill the lock & semaphore inlines before submitting upstream :) ***takane_ is now known as takane
***Noisytoot_ is now known as Noisytoot
***Noisytoot is now known as [
***[ is now known as Noisytoot
<Pellescours>today I have ../../libtrivfs/io-read.c:23:1: error: conflicting types for ‘trivfs_S_io_read’ when trying to build hurd, really weird, I just updated packaged compared to yesterday <youpi>the actually complete error message will tell <youpi>rebooting won't change anything :) <Pellescours>../../libtrivfs/io-read.c:23:1: error: conflicting types for ‘trivfs_S_io_read’; have ‘kern_return_t(struct trivfs_protid *, mach_port_t, mach_msg_type_name_t, char **, mach_msg_type_number_t *, off_t, mach_msg_type_number_t)’ {aka ‘int(struct trivfs_protid *, unsigned int, unsigned int, char **, unsigned int *, long long int, unsigned int)’} <Pellescours>./trivfs_io_S.h:48:15: note: previous declaration of ‘trivfs_S_io_read’ with type ‘kern_return_t(struct trivfs_protid *, mach_port_t, mach_msg_type_name_t, char **, mach_msg_type_number_t *, loff_t, vm_size_t)’ {aka ‘int(struct trivfs_protid *, unsigned int, unsigned int, char **, unsigned int *, long long int, long unsigned int)’} <Pellescours>youpi: yes, I rebooted because of gnumach updates :) <youpi>the vm_size_t type was upgraded to long, indeed <youpi>trivfs_S_io_read using mach_msg_type_number_t is bogus, it should be vm_size_t, as it has always been defined in io.defs <youpi>it seems various translators need fixing <youpi>there might be quite a few unfortunately :/ <youpi>also, it seems there are warnings about printing port names and such. We don't strictly need to fix them since %ld is equivalent to %d on x86-32, but ideally somebody would clean them :) <Pellescours>now it’s (sorry for putting the error message direcly but it’s faster than create a paste for each), I’m not sure of how I should fix it: <Pellescours>../../libpager/data-return.c:257:1: error: conflicting types for ‘_pager_S_memory_object_data_return’; have ‘kern_return_t(struct pager *, mach_port_t, vm_offset_t, pointer_t, vm_size_t, int, int)’ {aka ‘int(struct pager *, unsigned int, long unsigned int, long unsigned int, long unsigned int, int, int)’} <Pellescours> 257 | _pager_S_memory_object_data_return (struct pager *p, <Pellescours>In file included from ../../libpager/data-return.c:19: <Pellescours>./memory_object_S.h:123:15: note: previous declaration of ‘_pager_S_memory_object_data_return’ with type ‘kern_return_t(struct pager *, mach_port_t, vm_offset_t, vm_offset_t, mach_msg_type_number_t, boolean_t, boolean_t)’ {aka ‘int(struct pager *, unsigned int, long unsigned int, long unsigned int, unsigned int, int, int)’} <Pellescours> 123 | kern_return_t _pager_S_memory_object_data_return <youpi>it shouldn't be mach_msg_type_number_t but vm_size_t <Pellescours>If I understood correctly it’s the length parameter that should not be here <youpi>ah, the problem is converse here <Pellescours>do you rather I patch per file or one global for all fixes? <youpi>one global for all fixes will be fine <youpi>since it's all of the same many taimes <youpi>gnu_srs: I have found the gcc-12 issue <youpi>see ./libstdc++-v3/config/os/gnu-linux/os_defines.h <youpi># define _GLIBCXX_GTHREAD_USE_WEAK 0 <youpi>(but first I have to test it, that'll be long)