IRC channel logs

<ZhaoM>sneek later tell azert: ah indeed they can implement other chips in the same binary. They'd probably add --option so the same translator can act as different rtc drivers. I supposed implmenting a new rtc driver will need to create a new translator.

<sneek>Got it.

<ZhaoM>sneek later tell azert: thanks for reminding me, I will still call it rtc and submit a new patch.

<sneek>Got it.

<ZhaoM>sneek later tell azert: but I think for extensibility, I will still modify the name of the server-side implementation file (i.e. pioctl-ops.c to rtc-cmos-pioctl-ops.c) so people can know it's cmos specific

<sneek>Will do.

<damo22>youpi: someone from NetBSD is interested in having rump maintained again, so it sounds like he will be doing some more work on it "I would really like to see rump buildable and functional again in NetBSD"

<damo22>"if we can stabilise upstream (ie; NetBSD src) then I think it might also help your project."

<damo22>i gave him some encouragement and sent him a link to my "develop" repo that i will soon mail in patches for

<Pellescours>yay

<etno>I went a bit further with rumpusb, and I hit an initialization time-out in ehci (in qemu). I get device [un]plug events, though.

<damo22>i thought there was a problem with ehci that the mmap fails of the pci region

<damo22>some dma align issue?

<etno>This is the next thing I plan to investigate.

<damo22>etno: you can try my develop branch of rumpkernel

<damo22>i fixed compilation and a few bugs

<damo22>also linked with irqhelp

<etno>damo22: I'll try that. Do you have changes regarding mmap or alignment there ?

<damo22>no but i changed something relating to pci_map

<damo22>instead of pci_device_map_range i am using pci_device_map_region

<damo22>even though the api is deprecated, it seems silly to map an arbitrary range instead of a region that is already probed

<etno>pci-userspace-pcimap <- this deserves an attempt 👍

<damo22>?

<etno>I'll give it a try

<damo22>fetch and use the develop branch instead

<damo22>it has all of it merged together

<damo22>i deleted that old branch you mentioned

<damo22> https://git.zammit.org/rumpkernel-debian.git/log/?h=develop

<etno>pci-userspace-pcimap is the name of the quilt patch on the develop branch :-)

<damo22>oh yes sorry

<etno>No worries :-)

<youpi>damo22: good :)

<damo22>there was a problem with my git server that etno found he could not clone from it, it has been fixed

<ZhaoM>I'm playing with util-linux. When using autoconf to check the system, it will generate a variable which can be used in ac extension file called $host_os

<ZhaoM>On the hurd $host_os is "gnu0.9", on my arch linux it is "linux-gnu"

<ZhaoM>util-linux thinks the host is linux if $host_os match [*linux*]

<ZhaoM>so we can only add a conditional to make it thinks the host is GNU/HURD if $host_os match [*gnu*]

<ZhaoM>and the conditional must be behind that of "if $host_os match [*linux*]"

<ZhaoM>it seems to me that it is quite dangerous :/

<Pellescours> https://github.com/bminor/glibc/blob/master/configure.ac#L383

<Pellescours>if you set gnu* it wont match linux-gnu

<ZhaoM>ah thanks, this is what I'm looking for

<gnu_srs1>Hi, any ideas on how to replace mount/umount in C-code? Linux has them in libc while Hurd have them as standalone commands in Hurd.

<gnu_srs1>s/mount("proc", "/proc", "proc", 0, NULL)/system mount /proc/ or similar??

<azeem>gnu_srs1: what package is this?

<gnu_srs1>bootlogd.c from sysvinit

<gnu_srs1>bootlogd: ioctl(/dev/ttyp2, TIOCCONS): Inappropriate ioctl for device: Is that ioctl() wrong/not defined on Hurd? ioctl(pts, TIOCCONS, &on) pts=5, on=1

<gfleury>sneek later tell youpi: few days ago i have sent a pachset for pthread_contrattr_*. If you have a time this weekend take a look at it

<sneek>Okay.

IRC channel logs

2024-11-29.log