IRC channel 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>?

<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>yeah

<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>ok

<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.

<damo22>ok

<youpi>modularity is the hurd key :)

<damo22>yeah

<damo22>pci-userspace repo can be used to build all the rump libs including userspace pci support

<youpi>yes

<youpi>that's completely fine

<damo22>ok

<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

<damo22>ok

<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> https://github.com/rumpkernel/pci-userspace/commits/master :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>:(

<damo22>no, theres a bug in libpciaccess 0.16-1+hurd.1

<damo22>arrgh

<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)

IRC channel logs

2019-11-30.log