IRC channel logs

2024-08-08.log

back to list of logs

<damo22>sneek: later tell AlmuHS as far as i can tell, AHCI driver works by matching on PCI_CLASS and PCI_SUBCLASS etc, not by vendor and device id, only for quirks, so the current NetBSD ahci driver should work on most AHCI controllers according to ahci_pci_match(device_t parent, cfdata_t match, void *aux)
<sneek>Got it.
<damo22>sneek: later tell AlmuHS also, according to latest code, the ahci_pci_match code is exactly the same as what we have in our rumpkernel tree https://github.com/NetBSD/src/blob/trunk/sys/dev/pci/ahcisata_pci.c
<sneek>Will do.
<azert>damo22: I think that keeping pace with Netbsd kernel development, and specifically having a developer working on _both_ projects, is the only way to make the current strategy successful
<damo22>not really, i think if rump was supported properly upstream as a first class citizen in netbsd, we could just sync their tree
<damo22>we are basically compiling their src/ tree
<damo22>but the drivers dont all have rump targets in the makefiles
<damo22>thats the main issue
<azert>damo22: AlmuHS was saying that updating src/ gives a few errors. Also there are Debian patches that need to go upstream. Like you said some makefiles needs to update. Finally, netbsd people would surely be interested in supporting userspace drivers, as such there is a potential of synergy between the two projects
<almuhs>hi
<sneek>Welcome back almuhs, you have 2 messages!
<sneek>almuhs, damo22 says: as far as i can tell, AHCI driver works by matching on PCI_CLASS and PCI_SUBCLASS etc, not by vendor and device id, only for quirks, so the current NetBSD ahci driver should work on most AHCI controllers according to ahci_pci_match(device_t parent, cfdata_t match, void *aux)
<sneek>almuhs, damo22 says: also, according to latest code, the ahci_pci_match code is exactly the same as what we have in our rumpkernel tree https://github.com/NetBSD/src/blob/trunk/sys/dev/pci/ahcisata_pci.c
<almuhs>damo22: checking sources from cvs, i see commit like this, which add some PCI_VENDOR, including intel http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/ahcisata_pci.c.diff?r1=1.62&r2=1.63
<almuhs>and this http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/ahcisata_pci.c.diff?r1=1.63&r2=1.64
<almuhs>and checking the file itself, there are some commits more modern than 2021 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/ahcisata_pci.c
<almuhs>and this could be the reason because NetBSD 10 detects the hdd and cdrom, and our rumpdisk not
<almuhs>making a diff between your github file and the ours, i find many differences https://paste.debian.net/1325818/
<almuhs>repeating the patch with the ahcisata_pci.c from orig, i notice some differences too https://paste.debian.net/1325819/
<almuhs>check the Intel new lines
<gnucode>hello hurd friends. dino-im doesn't work today. :(
<almuhs>what is dino-im?
<gnucode>(dino-im:1308): GLib-GIO-ERROR **: 10:16:11.703: Settings schema 'org.gtk.gtk4.Settings.EmojiChooser' does not contain a key named 'recent-emoji'
<gnucode>dino-im is probably the best XMPP/Jabber client.
<gnucode>I use it for JMP.chat
<azert>almuhs: upgrading netbsd allowed the detection of the hdd, right?
<azert>Which means that old netbsd and rumpdisk share the same bug, and that current netbsd fixed it
<azert>Absolutely predictable that something like this would happen at some point
<almuhs>azert: yes, it is
<almuhs>the hurd's rumpdisk is using old sources
<almuhs>from 2021
<almuhs>but the current netbsd has some modifications in rumpdisk
<almuhs>someone of these add some specific vendors for some Intel models