IRC channel logs


back to list of logs

<damo22>youpi: should i exclude both PCI CFG1 and CFG2 regions from ioperm in rump?
<damo22>its just that ive seen qemu use CFG2 region for actual devices
<damo22>so i dont know if its a qemu bug or whether we should actually change gnumach to not care about CFG2
<youpi>damo22: I'm not sure to understand exactly
<youpi>normally rump doesn't need to access cfg1 and cfg2 since it uses libpciaccess?
<damo22>youpi: in rump pci-userspace project, io ports must be given to drivers therefore it asks for ioperm
<damo22>but we should be excluding the regions that we reserve using gnumach lock
<youpi>but drivers aren't supposed to touch pci config and rather politely ask from the core?
<damo22>uhh, pci-arbiter does not support that
<youpi>it has config read/write support
<youpi>what drivers would need to use cfg1/2 for?
<damo22>i mean, previously, pci-userspace project was running ioperm() on the whole region
<damo22>its not necessary
<damo22>as in, rump was previously asking for all ioports
<damo22>so a first step i did was to exclude the cfg1 region from the request
<damo22>since it will never need that
<damo22>but my question is, do i need to exclude cfg2 as well
<damo22>the reason i am asking, is because ive seen qemu use cfg2 region for ahci io ports
<damo22>so if i exclude cfg2 i would not be able to use ahci with rump under qemu
<youpi>damo22: where did you see that in qemu's ahci?
<damo22>lspci -vv
<damo22>ioport 0xc060
<damo22>Region 4: I/O ports at c080 [size=32]
<damo22>is that a qemu bug?
***Server sets mode: +nt
<youpi>and the actual device driver doesn't need to tinker with it
<damo22>oh ok
<damo22>so should i exclude asking for access to it
<youpi>linux' ahci drivers don't contain any inb/w/l
<damo22>in rump
<youpi>I believe that should be fine
<youpi>the drivers don't have to touch pci config, only the pci initialization needs to do it
<damo22>so i need to alter my patch before merging it upstream in rump
<damo22>to exclude pcicfg2
<damo22>currently i only excluded pcicfg1
<damo22>i have commit access to pci-userspace
<youpi>seen that, congrats :)
<damo22>do you think the repo should live in debian?
<damo22>or somewhere not on github
<youpi>? why so?
<damo22>the maintainer was asking if we want to move it somewhere
<youpi>why would we do it?
<damo22>because it only supports hurd + linux
<youpi>that's already two good reasons :)
<damo22>and we are the active developers
<damo22>it hasnt been touched since 2016
<youpi>better develop at the right place than going somewhere else alone
<damo22>"Also, does it make sense for the code to live in this repo if you get it merged into HURD? Just supplying food for thought. "
<youpi>? I don't think we'll merge it into hurd
<youpi>we'll use it
<youpi>just like we use libparted, libpciaccess, etc.
<youpi>modularity is the hurd key :)
<damo22>pci-userspace repo can be used to build all the rump libs including userspace pci support
<youpi>that's completely fine
<damo22>and now we have commit access we can tweak it if needed
<damo22>but it currently works with ahci
<damo22>(but requires some netbsd-src changes)
<damo22>i wish i can upstream these but its difficult
<youpi>this kind of this require discussion yes :)
<damo22>maybe i can add a debian package that has patches
<youpi>we can upload anything we want to unreleased anyway
<damo22>should i focus on packaging rump libs via pci-userspace?
<damo22>with the new ahci libs
<youpi>it'd be useful
<youpi>I can easily upload things that are ready to be uploaded :)
<damo22>it has a build static mode that seems to be different from _pic.a
<damo22>is that what i should be linking to rumpdisk.static
<youpi>I don't know
<damo22>i'll ask rump guys
<damo22> :D
<youpi>yay !
<damo22>i wonder if there's any way to run hurd in a travis CI
<damo22>then we could do unit testing in there
<youpi>that'd be useful
<youpi>btw, about debian packages for rump, remember that robert millan did some work some years ago, leverage that ;)
<damo22>oh yes
<damo22>how do i build a debian package without expecting the upstream tarball in ..
<damo22>-nc works, but doesnt apply any of the patches in debian/patches
<damo22>i packaged rump!!
<damo22>looks like hurd cannot access the AHCI card via rump with the pci cfg2 blocked
<damo22>no, theres a bug in libpciaccess 0.16-1+hurd.1
<damo22>the patches you applied to libpciaccess break rump
<damo22>it fails to probe the ahci
<damo22>i can send you patches for rumpkernel debian package that will build a working rumpdisk
<damo22>youpi: looks like netbsd's sound api is better than linux
<damo22>you can get accurate buffer pointers from ioctls
<damo22>and it uses bus mastering on dma
<damo22>we dont need OSS
<gnu_srs1>I have now cross-compiled ncurses with terminfo support and nano. Running nano in a Hurd vm does now complains: LD_LIBRARY_PATH=. ./nano
<gnu_srs1>Error opening terminal: xterm-256color.
<gnu_srs1>Even copying e.g. xterm to /tools/lib/terminfo/x/ fails:LD_LIBRARY_PATH=. TERMINFO=/tools/lib/terminfo TERM=xterm ./nano
<gnu_srs1>Segmentation fault
<gnu_srs1>What am I doing wrong? nano worked before adding terminfo support to ncurses(w)