<damo22>youpi: would it be a good idea to move the user interrupt handler creation to a library eg, libirq so that zheng da's code can be reused from pci-userspace in hurd eg, for other client drivers that need interrupts? <damo22>i am already looking at acpi which will need almost identical code there <youpi>if you can work out a convenient API that can be useful yes <damo22>acpica has an api for that which is almost what we need <damo22>acpi_os_install_interrupt_handler(u32 gsi, acpi_osd_handler handler, void *context) <damo22>acpi_osd_handler is a function pointer that takes a void * <damo22>i think we might also need a field int irq_thread_priority and some kind of way to pass in two functions that can wrap around the interrupt call to the handler <damo22>like a struct of function pointers with an .init .pre and .post hook and void * pointers for the arguments <youpi>I don't see why such technical complexity? <youpi>if you have things to do before/after the handler, you can just interpose the handler <damo22>what about calling something in the interrupt thread to initialise something <youpi>the lib doesn't have to start the thread itself <youpi>just like libports doesn't start the main mux loop itself <damo22>so then the api is almost fine as is <damo22>we could make a second one accept bus dev fun instead of gsi, and have it call the irq lookup <damo22>i need it so i can fix the TODO in libacpica yes <damo22>native hw is hanging on intnull(9) on my latest patchset <damo22>because acpi does not know how to register the handler <mhatta>Seems ok, but I have problem on setting up static network <mhatta>What do I need to do after installation? <damo22>mhatta: i have patches in the pipeline that should address this problem but you should be able to work around it <damo22>eg, you could use "settrans /servers/socket/2 /hurd/pfinet ..." with the correct other options <mhatta>FUGA Cloud is based on openstack, so I could set property "hw_vif_model=rtl8139" etc., so emulated NIC should be detected ***wyre_ is now known as wyre
<youpi>mhatta: you can simply use inetutils-ifconfig <mhatta>youpi, thanks, but somehow ifconfig doen't work for setting netmask <mhatta>settrans works beautifully and now ping can be reachable! yay! <youpi>ifconfig doesn't work, more precisely? <mhatta>like "ifconfig /dev/eth0 -m 255.255.254.0" are ignored <youpi>are you sure you're using inetutils-ifconfig and not ifconfig? <youpi>there's an ifconfig from another implementation, that may not be that well supporting the hurd <youpi>e.g. use "dpkg -S ifconfig" to make sure which implementation "ifconfig" is provided from <mhatta>ah I didn't know there are two implementations <youpi>and if it's really inetutils-ifconfig that fails to set netmask, better actually report the problem to inetutils <youpi>rather than keeping having to settrans by hand <youpi>which package is that ifconfig coming from? <mhatta>hmm, weird, seems ifconfig is actually from inetutils-ifconfig <youpi>which command did you use to determine that? <biblio>youpi: as far I remember inetutils-tools provides inetutils-ifconfig <mhatta>dpkg -S ifconfig gives ifconfig comes from inetutils-tools deb <youpi>yes but the one I know does work <mhatta>and type ifconfig gives /usr/bin/ifconfig <youpi>the question is what package the one that doesn't work comes from <youpi>mhatta: use dpkg -S ifconfig <youpi>please really read what I write <youpi>ah sorry it got mixed with the message above *youpi should perhaps just stop answering #hurd while at work, not enough attention available <youpi>does it say exactly that it's ifconfig that comes from inetutils-tools, and not inetutils-ifconfig? <mhatta>well, as far as I could see, there is only one ifconfig, which comes from inetutils-tools <youpi>is it called ifconfig or inetutils-ifconfig <mhatta>but somehow if I call it by just "ifconfig", -m opetion seems to be ignored <mhatta>if I run inetutils-ifconfig, it works <youpi>which is why I'm talking about the difference between ifconfig and ineutils-ifconfig <youpi>is ifconfig a symlink nto inetutils-ifconfig <biblio>mhatta: cloud you please check if your ifconfig is an alias of inetutils-ifconfig ? <youpi>and is ifconfig (not inetutils-ifconfig) actually really shown in the inetutils-tools package? <mhatta> /usr/bin/ifconfig is a symlink to /usr/bin/inetutils-ifconfig <youpi>biblio: he already said type ifconfig gives /usr/bin/ifconfig <youpi>so it's really the same implementation <youpi>apparently it changes behavior depending how it's called <youpi>but it misses changing its --help to reflect that <youpi>ifconfig /dev/eth0 10.0.2.15 netmask 255.255.254.0 does work , for instance <youpi>which is indeed the ifconfig way of using it <youpi>so the report is still to inetutils-tools, but telling it that it should change --help when called ifconfig <mhatta>I might be confused, I'll investigate this a bit more <mhatta>anywise, now network works, that's important ;-) <youpi>looking at the source, it doesn't seem to be changing behavior <youpi>(11:34:29) mhatta: if I run inetutils-ifconfig, it works <youpi>inetutils-ifconfig /dev/eth0 -m 255.255.254.0 <youpi>takes the address as IP address, not netmask <biblio>youpi: 255.255.255.0 may be a typo in 3rd 254 ! <youpi>it's meant to be so, precisely to test that it's working <biblio>youpi: oh sorry I am bit confused now :D <youpi>.254 is completely valid for a netmask <biblio>youpi:ok got it. yes it is valid in indeed. ***AndrewYu is now known as Andrew
***Noisytoot_ is now known as Noisytoot
***073AAK6Z9 is now known as valeriusN