IRC channel logs


back to list of logs

<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
<damo22>.init .pre .handler .post
<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>ah ok
<damo22>yes that simplifies things
<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>ok i will work on this lib next
<youpi>perhaps call it libirqhelp?
<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
<damo22>gtg to work
<biblio>luckyluke: ok
<mhatta>So I installed Debian GNU/HURD on FUGA Cloud( using debian-hurd.img
<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
<mhatta>damo22, thanks, I'll try
***wyre_ is now known as wyre
<youpi>mhatta: you can simply use inetutils-ifconfig
<youpi>please read
<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" are ignored
<mhatta>netmask can't be changed
<youpi>that works for me
<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
<mhatta>ok, inetutils-ifconfig works
<mhatta>ifconfig doesn't
<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?
<youpi>details always matter
<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>like I wrote
<youpi>please really read what I write
<mhatta>youpi, please read what I write
<mhatta>I did use dpkg -S
<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
<youpi>or another file
<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 netmask 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>thanks for helping
<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>it doesn't here
<youpi>inetutils-ifconfig /dev/eth0 -m
<youpi>takes the address as IP address, not netmask
<biblio>youpi: may be a typo in 3rd 254 !
<youpi>biblio: no it's not a typo
<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