<youpi>damo22: can't pci_port be passed as a parameter to enum_devices ? <youpi>I don't see anything else needing it beyond enum_devices <youpi>ah, it's already passed as root port, but can't pci_system_hurd_create just release it? <damo22>it would need to be another param i guess <youpi>ah, when recursing you pass another port ok <youpi>Mmm, but you overwrite the cwd_port parameter anyway? <youpi>i.e. you just need to keep the root port at each call, and not pass the cwd_port ? <damo22>ive had tons of iterations on this, i forget how it works <youpi>since it's the "parent" path that grows <damo22>i had it working with and without dir_readdir at one point, so when i cleaned it up i probably overlooked it <damo22>do you want me to remove the global port? <youpi>global variables are usually ugly :) <youpi>for the sort part, discussion would probably be needed with upstream. I'm not sure to understand: are you saying that you are getting duplicated entries if you don't sort entries? <youpi>pci-arbiter is not supposed to provide duplicated entries like that <youpi>it looks to me like another bug that shall be fixed <damo22>yes there are dups if the list is not sorted <damo22>but when you sort both the x86 ones and the hurd ones, no more dups <damo22>so it kind of makes sense to sort inline <youpi>are you probing both with the x86 and the hurd methods ? <youpi>I mean, upstream will frown quite a bit if only one backend needs such kind of sorting, while usually backends simply provide the proper list already <damo22>yes, because the static arbiter uses the x86 method, and exposes hurdish method, then the rumpdisk probes using hurdish? <youpi>they aren't in the same process <youpi>so rumpdisk will have its own list, from the hurd method <youpi>there is no reason for duplicates here <youpi>it'll just get the list from the the static arbiter <damo22>yes but the duplicates arise from the pcifs.c being stupid <youpi>can't we provide a sorted list? <youpi>no I mean can't we just always have it sorted, from the start? <damo22>but its easier to have it upstream <youpi>how is it that it's not keeping in the right order ? <damo22>the x86 method has some recursion that does not generate the list in order or something <youpi>I don't see how that coujldn't have posed problems before already <youpi>and now pose problem that we'd have not seen before <damo22>it was coincidence that qemu does not have issues <damo22>we need to have the list in order in libpciaccess <damo22>or every time we use it, sort them <youpi>what I don't understand is how we'd end up in non-sorted order <youpi>pci_system_x86_scan_bus does probe in order <youpi>so I don't see how x86 could be building a non-ordered list <damo22>i dont know, it gets out of order <youpi>and that's to be fixed rather than brown-tape it <damo22>maybe the hurd method of recursion does not work <youpi>put prints, and you'll see how the recursion proceeds <damo22>all i know is, when i sort the devices after they are generated for both backends, everything works nice <damo22>Asking all remaining processes to terminate...killall5: can't read from 5/stat <damo22>killall5: can't read from 6/stat <youpi>pci-arbiter creates its entries in the order provided by pci_devices_next() <youpi>so I believe at least the hurd method doesn't need the sort <youpi>case PCI_HDRTYPE_BRIDGE: pci_system_x86_scan_bus (secbus); <youpi>I guess possibly your hardware has a bridge, and that indeed will mix up buses <youpi>so the x86 backed would then need sorting after probing everything <youpi>that I guess upstream would understand and accept ***Server sets mode: +nt
***Server sets mode: +nt
<youpi>- .destroy = pci_system_x86_destroy, <damo22>we cant unless we have a global for the port <damo22>how would i pass in the pci_port? <youpi>? x86_destroy doesn't use the pci_port ? <youpi>? are we talking about the same thing ? <youpi>I'm talking about pci_system_x86_destroy <youpi>well, the hurd_pci_methods structure <damo22>i removed it because i had another method there <youpi>in the previous patch yes, but now you can restore it <damo22>but i couldnt work out how to close it without the port passed in <youpi>I mean restore leaving it as it was :) <damo22>does it even matter? do we need to close io ports on hurd? <damo22>i suppose if we lock them in kernel it matters <youpi>yes, and also to let the process avoid keeping i/o privileges after closing libpciaccess <youpi>(I guess you tested that e.g. netdde is still working fine with this updated libpciaccess?) <damo22>yeah i booted with settrans /servers/bus/pci /hurd/pci-arbiter.static recompiled with my changes <damo22>but i have not tested the dynamic lib <damo22>with existing pci-arbiter linked dynamically to new libpciaccess, i get :fsysopts: /servers/socket/2: -i /dev/eth0 -a 0.0.0.0 -m 255.0.0.0: (ipc/mig) server died <damo22>Error getting interfaces; Translator died <youpi>settrans the translator with -a to get messages of the translator <damo22>root@zamhurd:~# settrans -a /servers/bus/pci /hurd/pci-arbiter <youpi>I mean the translator that dies <youpi>apparently here it's pfinet that dies, probably out of netdde dying as well <damo22>if netdde is already running i get settrans: /dev/netdde: Device or resource busy <youpi>you can kill it or use -fg along -a <youpi>then settrans pfinet by hand as well <damo22>/hurd/pfinet: device_open on /dev/eth0: (os/device) no such device <damo22>but /dev/eth0 is a devnode to /hurd/netdde <youpi>did netdde not find the ethernet card? <damo22>00:02.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection <damo22>i cant tell but last line is l4dde26_register_rx_callback: New rx callback @ 0x1047630. <damo22>it probes a lot but does not mention eth0 <damo22>maybe the path needs to be _SERVERS_BUS_PCI instead of "." for the fallback path <damo22>so there could be another conditional in there <youpi>no, it's a relative path since you use file_name_lookup_under <damo22>yea but the "under" pathway might fail and then it uses file_name_lookup only? <youpi>it just looks up in the dir port <youpi>pci_system_hurd_create does file_name_lookup (_SERVERS_BUS_PCI <youpi>and then it passes that to enum_devices <youpi>and enum_devices uses relative paths from there <youpi>relative to the root port it's given <damo22>ok so i dont know why this is failing <youpi>iirc that's what we have currently <damo22>i thought it might be a symlink thing but it looks okay <damo22>because now there is a new thread for machdev <damo22>and i did not install the libmachdev.so <damo22>maybe netdde needs a pthread_exit(NULL) <youpi>ah yes it needs to be refreshed, see my latest commit in the incubator <youpi>(actually, your change that I commited) <damo22>i think the pci entries are broken in netfs_impl.c and only got fixed in my version of the arbiter <damo22>there is something fishy going on in the existing arbiter that does not play nice with the updated libpciaccess <damo22>it could even be the count variable that you pointed out <damo22>because we are requesting exactly one directory entry at a time and looping over them <damo22>ok have submitted upstream to libpciaccess <damo22>ok i split my patches for pci-arbiter and found a subset that can be applied as is ***rekado_ is now known as rekado
***TigerbotHesh is now known as Guest90648