IRC channel logs


back to list of logs

<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>all packages are up to date
<Pellescours>I found the fix, it’s a missing "#include signal.h"
<Pellescours>patch sent
<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> is the dst for a default gw?
<youpi>you need to know the destination+mask, and the gateway to go through
<youpi> 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>which code?
<damo22>eg, pfinet/options.c
<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
<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>i thought it was per route
<youpi>one netmask per IP you have
<youpi>it's also per route
<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>thats ok
<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>found it rtm_dst_len
<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>(gdb) p *r
<damo22>$1 = {rt_dest = 257, rt_mask = 4294967295, rt_gateway = 0, rt_flags = 2, rt_mtu = 0}
<damo22>(gdb) p *r
<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>the rtmask looks it
<youpi>it's supposed to be all-ones starting from most significant bits
<youpi>or is it in network order?
<damo22>network order
<youpi>they still look fishy
<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>so it's very hard to tell
<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>(gdb) p err
<damo22>$6 = EINVAL
<damo22>how did gdb know the macro??
<damo22>thats very cool
<damo22>youpi: now i get dhcp broadcast to 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>in options.c
<damo22>my understanding:
<damo22>entry0: dest=anywhere with mask=mask -> gateway=gateway
<damo22>entry1: dest=host (no mask)
<damo22>DHCPDISCOVER on /dev/eth0 to 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>hooray! it works
<damo22>youpi: i got #define EMIG_BAD_ARGUMENTS -304
<damo22>returned from my ioctl
<damo22>but i think the route works
<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 ?
<damo22>its a patch on the mailing list
<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>TIL, an ipv4 fits in uint32_T
<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
<damo22>ive created a new file for that
<damo22>can i push that?
<damo22>it works
<damo22>no more missing symbols :D
<damo22>youpi: if its okay, i will push this to ours
<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>to minimise the new file
<youpi>you can, yes
<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
<damo22>why cant i just use inline?
<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
<youpi>then make these into the .c
<youpi>(that need it)
<damo22>youpi: can i push this to master?
<damo22>i tested by statically linking it to a main and calling acpi_init
<youpi>that looks good, yes
<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>oh yes
<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
<damo22>the dynamic one is tiny!
<damo22>ok pushing to master
<youpi>damo22: note that you can use lintian on the .changes file to tell you bugs ni the packaging
<youpi>I have now pushed it
<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>possibly the mig upgrade
<youpi>the actually complete error message will tell
<Pellescours>I reboot, but yeah I think it’s a mig update
<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> 23 | trivfs_S_io_read (struct trivfs_protid *cred,
<Pellescours> | ^~~~~~~~~~~~~~~~
<Pellescours>In file included from ../../libtrivfs/io-read.c:19:
<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> 48 | kern_return_t trivfs_S_io_read
<Pellescours> | ^~~~~~~~~~~~~~~~
<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>(patch welcome of course)
<Pellescours>I’m doing it :D
<youpi>good :)
<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> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<Pellescours>In file included from ../../libpager/data-return.c:19:
<youpi>that's the same problem
<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
<Pellescours> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<youpi>it shouldn't be mach_msg_type_number_t but vm_size_t
<Pellescours>there is no mach_msg_type_number_t int he method
<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>I'm setting up a patch
<youpi>(but first I have to test it, that'll be long)