IRC channel logs

<ZhaoM>Good morning \o/

<damo22>hi

<damo22>ZhaoM: well done on rtc

<damo22>does it work with hwclock?

<ZhaoM>I'm now trying to figure out how to add something in util-linux

<ZhaoM>It's called util-linux

<ZhaoM>but it seems it provides utility programs for many OS :/

<damo22>grep rtc

<ZhaoM>Samuel said

<ZhaoM>The code from sys-utils/hwclock-rtc.c (read_hardware_clock_rtc,

<ZhaoM>set_hardware_clock_rtc) can be moved out to another file, that a hurd

<ZhaoM>version could use (you'd add a "HURD =" line along the LINUX and BSD

<ZhaoM>ones in meson.build:130). And you should then be able to play with

<ZhaoM>hwclock to manipulate the RTC.

<ZhaoM>I'm trying to understand how "be moved out" and "HURD =" work

<damo22>292MB is a lot for a utility suite

<damo22>ZhaoM: did you implement it as an ioctl?

<damo22>or an RPC

<ZhaoM>..from my point of view, what I implemented is both ioctl and RPC, not sure if I confuse it

<ZhaoM>but you can try to use it

<ZhaoM>apply the v3 patch I just sent in the mail list

<damo22>if it has the exact same api as linux, it should just work

<damo22># define RTC_PARAM_GET _IOW('p', 0x13, struct rtc_param)

<damo22># define RTC_PARAM_SET _IOW('p', 0x14, struct rtc_param)

<ZhaoM>#define RTC_RD_TIME _IOR('p', 0x09, struct rtc_time) /* Read RTC time. */

<ZhaoM>#define RTC_SET_TIME _IOW('p', 0x0a, struct rtc_time) /* Set RTC time. */

<ZhaoM>they are different...

<damo22>no mine is a different part of the api

<ZhaoM>it should be find, I copied RTC_RD_TIME and RTC_SET_TIME from linux source code

<ZhaoM>s/find/fine/

<damo22>you should look at /usr/include/linux/rtc.h on a linux system

<damo22>there are more ioctls

<ZhaoM>I realised that, but i think the other ioctls is less important so I haven't implemented them. I will do it later

<damo22>or look at hwclock-rtc.c to see what is necessary to implement

<damo22>$ grep ioctl hwclock-rtc.c |grep RTC_ |grep -vE 'warn|printf'

<damo22>seems to use these ioctls

<damo22>but check if they are needed

<ZhaoM>ok

<damo22>you may need to implement them as stubs that return 0

<damo22>idk

<damo22>but did you check that your structs are the same format

<damo22>if theyre not exactly the same sized and layout as linux, then util-linux code will be confused

<damo22>or you will need to rewrite the functions

<damo22>on the util-linux side

<ZhaoM>yeah i have confirmed i used the same format

<youpi>it's not really a requirement to implement all the ioctls

<youpi>the set I mentioned in my mail is enough to get essentially all that we really need

<youpi>these functions can be put in a separate .c file

<youpi>that both the linux build and the hurd build can use

<youpi>the linux build would then also include the other functions, which provides a bit more support

<youpi>while the hurd can be fine with what we already have

<youpi>ZhaoM: : "HURD =" : see the meson.build file at line 130

<youpi>it's simply an os-specific meson condition

<youpi>to build the tools differently on linux, bsd, and hurd

<ZhaoM>youpi: is it something like #ifdef HURD ... #endif in source code? but it's used in meson

<youpi>that's the same kind of idea, yes

<youpi>at the whole-file compilation level

<ZhaoM>got it

<damo22>/usr/bin/ld: /usr/lib/gcc/i686-gnu/14/../../../librumpdev_pci_if_wm.a(if_wm.o): in function `wm_init_locked':

<damo22>(.text+0x130f7): undefined reference to `rumpns_rss_getkey'

<damo22>youpi: https://paste.debian.net/plain/1337235

<damo22>rumpnet is coming

<etno>Nice !

<youpi>\o/

<etno>AIUI, after we have a network driver which is compatible with shared IRQs, we will change the rumpdev PCI IRQ handler to ACK only when rump's driver returns 1. Is this correct?

<damo22>i cant seem to figure out how to send a packet with rumpnet

<damo22>there must be an example in the netbsd source tree

<youpi>etno: I don't see why

<youpi>the general idea is to notify all drivers sharing the same irq, and just wait for all of them to have run their respective handler before acking the interrupt

<etno>youpi: Ohh, ok ! I thought that one and only one had to ACK.

<janneke>damo22: wo0T!

<damo22>apparently i need to look at shmif and shmif_pcap

<damo22>shmif_pcapin*

<Pellescours>damo22: https://github.com/NetBSD/src/blob/trunk/sys/net/if_ethersubr.c ?

<damo22>libshmif

<damo22>rump_shmif_create(const char *path, int *ifnum)

<ZhaoM>hi any method to increase the ext2 file system size of my debian-hurd.img file?

<ZhaoM>I've enlarged the disk size

<ZhaoM>but I haven't found a way to increase the file system size

<damo22>ZhaoM: you need to enlarge the partition size, and then run resize2fs i think

<ZhaoM>damo22: in the virtual machine? It said I cannot run resize2fs on flight

<ZhaoM>on fly

<damo22>yeah it needs to be unmounted

<damo22>but you cant do it on mounted root i think

<ZhaoM>Filesystem at /dev/hd0s2 is mounted on /, and on-line resizing is not supported on this system.

<ZhaoM>Do you mean unmount the root file system in the virtual machine?

<damo22>you cant i think

<ZhaoM>ok :/

<damo22>can you shut it down and resize2fs in the host?

<youpi>you neded to do it from outside, yes

<ZhaoM>youpi: which command should I use?

<youpi>as mentioned, resize2fs

<damo22>it depends on your setup

<ZhaoM>damo22: it seems resize2fs only accepts a /dev/

<youpi>you can use losetup to create one

<Pellescours>ZhaoM: losetup /dev/loop0 disk.img; partprobe /dev/loop0; resize2fs /dev/loop0p2

<damo22> * A virtual ethernet interface which uses shared memory from a

<damo22> * memory mapped file as the bus.

<Pellescours>all need to be done with root privileges (sudo), assuming that your disk image and partition was already grown

<youpi>damo22: that's not what you want, I believe

<damo22> * Virtual interface. Uses hypercalls to shovel packets back

<damo22> * and forth. The exact method for shoveling depends on the

<damo22> * hypercall implementation.

<damo22>if_virt.c

<ZhaoM>Pellescours: it works! Thank you

<ZhaoM>damo22, youpi: thank you for your help guys!

<youpi>damo22: since the logs say wm0, it'd be /dev/wm0 that you'd want to open inside rump

<damo22>youpi: i cannot rump_sys_open(/dev/wm0)

<youpi>ah but bsd doesn't expose ethernet interfaces in /dev

<damo22>someone told me they usually use a RAW socket

<damo22>and perhaps bpf

<youpi>that could probably work yes

<azert>damo22: I think you need to use getsock or similar, I don’t remember the details

<damo22>but is bpf the equivalent of the entire network stack on bsd?

<youpi>no

<youpi>it's just a way to filter what packets you want to receive

<youpi>tcpdump uses it for instance

<damo22>ok so i probe the device and it loads in the rump kernel, then i open a raw socket

<damo22>in rump land

<youpi>yes

<youpi>and you can get inspiration from tcpdump to receive the packets

<damo22> if ((socket_afnet = rump_sys_socket(AF_INET, SOCK_DGRAM, 0)) == -1)

<youpi>probably it essentially means uploading a catch-all bpf program into the kernel for the socket

<youpi>you don't want an inet dgram socket

<youpi>but a raw socket

<youpi>see how tcpdump does it

<damo22>ok

<azert>sneek: later tell ZhaoM I don’t agree with calling the rtc translator rtc-cmos. Foremost your implementation is not anymore cmos specific than x86-pc specific. Furthermore, if anyone would implement any other rtc chip, he’d probably do that in the same binary

<sneek>Will do.

<ZhaoM>hi

<sneek>ZhaoM, you have 1 message!

<sneek>ZhaoM, azert says: I don’t agree with calling the rtc translator rtc-cmos. Foremost your implementation is not anymore cmos specific than x86-pc specific. Furthermore, if anyone would implement any other rtc chip, he’d probably do that in the same binary

IRC channel logs

2024-11-28.log