IRC channel logs

<Zopolis4>does gnumach have mach/host_info.h but not mach/mach_init.h?

<youpi>€ dpkg -S mach_init.h

<youpi>libc0.3-dev:hurd-i386: /usr/include/mach_init.h

<youpi>not sure what you're looking for in it

<youpi>note that macosx also uses a mach-based kernel

<youpi>which has diverged from the common ancestor with gnumach

<Zopolis4>im looking through failed package logs for overmatching mach ifdefs https://www.irccloud.com/pastebin/TnZZPkCu/

<Zopolis4>one that trigger on hurd when they should only trigger on apple

<youpi>that's more probably looking for an ifdef for macos

<Zopolis4>wdym

<youpi>the source code that fails is probably missing an #ifdef to check it's on macox

<youpi>e.g. checking the apple macro

<Zopolis4>yeah but given that mach_init exists on hurd

<youpi>mach/mach_init.h doesn't exist

<Zopolis4>ah

<youpi>again, I'm wondering that the source code is looking for exactly

<youpi>what it thinks will get when including mach/mach_init.h

<youpi>it seems that it's similar to the gnumach mach_init.h

<youpi>but again, check the sourc ecode

<youpi>to see what it's doing with it

<youpi>most probably it's calling macos-ish functions then

<youpi>possibly not, but probably yes, but possibly not

<youpi>so just check the sourece

<Zopolis4>yeah im doing that

<damo22>i'll have a look at the source again for rioctl, as im not sure what i should do

<youpi>just like iioctl / tioctl

<youpi>it's just another series

<youpi>it doesn't exist yet

<youpi>but just copy/paste what there is for iioctl and tioctl, and that'll probably just work

<Zopolis4>yeah ok its calling host_cpu_load_info which i cant find in the gnumach sources

<damo22>i guess i need to create a new file rioctl.c and a rpc class?

<youpi>Zopolis4: so probably macos-ish, and you want to use the apple macro

<youpi>damo22: you can as well put functions in iioctl.c along the other, that's not really a problem

<youpi>but we'll need an rioctl.defs yes

<youpi>and run the rioctl server

<damo22>+ char ifname[IFNAMSIZ]; but the IOT has IF_NAMESIZE

<youpi>where?

<damo22>in the patch you sent on the libc mailing list

<youpi>see the subsequent commit

<damo22>ah sorry

<damo22>yes it looks good now

<damo22>i just need to use 'r' instead of 'i' etc

<Zopolis4>have submitted patches to restrict overmatching mach ifdefs for 16/23 packages

<Zopolis4>3 of them dont easily allow submission, so ive opened issues for 2 of those

<Zopolis4>cant find an easy way to deal with the cern one

<Zopolis4> https://github.com/google/highwayhash/blob/master/highwayhash/os_specific.cc#L43

<Zopolis4>i like the effort

<youpi>we've also see #ifdef linux #include <linux/foo.h> #else #include <windows.h> #endif

<damo22>youpi: should i write a patch that replaces all instances of IFNAMSIZ with IF_NAMESIZE in hurd?

<damo22>it seems more compatible?

<youpi>in hurd no

<youpi>since we build with _GNU_SOURCE there

<damo22>ok thanks. I found a missing stub and implemented it in lwip

<damo22>although i just made it return

<damo22>looks like the tree is back into shape

<damo22>thanks youpi!

<Zopolis4>ok mach ifdefs are done

<Zopolis4>what nexr

<youpi>there's also the sys/sysctl.h header

<youpi>sys/endian.h also

<Zopolis4>yeah there are 331 no such file or directory errors

<damo22>i hate the standard way of handling endianness: *(uint32_t *)blah; if bad, swap

<youpi>asm/byteorder as well

<youpi>damo22: standard ?

<youpi>I don't I remember having seen such a thing

<damo22>like, they just cast a struct member to an int

<damo22>and if its the wrong way around, they swap it

<damo22>its everywhere in linux

<damo22>there is a way to fix it

<youpi>that's a usual thing for magic numbers, but I haven't seen for other fields

<damo22>just use bitshifting

<damo22>the magic numbers are supposed to tell you which way around the buffer is

<damo22>but reading the fields should be done with bitshifting not swaps

<youpi>? swaps are bitshifts behind

<damo22>yeah but casting the struct from a memory address is not really correct until you swap it

<youpi>? how could you swap it before casting?

<damo22>read each field with shifts

<youpi>perhaps actually showing an example would allow to understand what you are after

<damo22>ok

<damo22>hmm i cant seem to find it in linux kernel anymore

<damo22>git grep "*((struct" doesnt pick up much these days

<damo22>like the usual way of reading a binary format is that they cast the memory containing a copy of the file to a struct, and call a conditional swapping function depending on host endianness, but that conflates the endianness of the buffer with the cpu's default order, thus requiring a swap on some machines. if you just read each field with b[0] | b[1] << 8 | b[2] << 16 ... it doesnt have any issue

<youpi>but that kind of reading is a swap too

<youpi>and in the end what matters most is the readability of the source code

<damo22>it should not matter what endianness is of the host

<damo22>you can call the same code

<youpi>that's swapping on read is for

<youpi>so after the swap you don't have to care

<damo22>middle endian will break

<youpi>? no

<youpi>swapping will achieve it

<youpi>and then you can just read in host order

<damo22>ok fine

<damo22>i still think its wrong to define swap functions everywhere

<damo22>theyre not neded

<youpi>but at some point you have to swap anyway

<youpi>be it at file read time with a swap function

<youpi> or later on with bit shifts

<damo22>yes

<youpi>better do it once at read, and be done with it

<youpi>but again, we're talking out of thin air. Without an actual example, we can't really argue properly

<damo22>the buffer exists in memory, its a stream not a struct

<damo22>casting it to a struct is just wrong

<youpi>why?

<youpi>again, really an exemple would really really help to understand what you're after

<youpi>other all I can think of does make sense to me

<youpi>read(buf) then cast it to a struct, then swap the fields so it's in the proper order, and then you can play at will with it

<damo22>unless you pack the struct gcc might pad it differently

<youpi>I don't see a problem here, that's the most maintainable way of doing it

<damo22>then youre up shit creek

<youpi>sure

<youpi>thus you pack

<youpi>so?

<damo22>bitfields are not good either

<damo22>they are dependent on host order

<youpi>sure

<damo22>why?

<youpi>but as long as you get control on how your compiler works, you can get away with it

<youpi>been there, had to do that

<youpi>was hidden in the struct itself

<youpi>the real source code doesn't actually care

<damo22>why cant gcc keep bitfields in a fixed order

<youpi>"why": there is no answer, since different compilers have different behavior, precisely :)

<youpi>because in some situations it makes sense

<youpi>in others it doesn't

<youpi>little/big endian

<youpi>same story

<youpi>no need to keep arguing

<damo22>k

<youpi> https://gitlab.freedesktop.org/slirp/libslirp/-/blob/master/src/ip.h#L75

<youpi>I have to say the gcc behavior makes more sense to me here

<damo22>eww

<damo22>i need to figure out how to test libirqhelp

<Pellescours>a test with usb maybe?

<youpi>or with netdde?

<damo22>yeah netdde maybe

<damo22>is that in libddekit?

<damo22>woot it works (with a few changes)

<iska>how much effort would it to put virtio disk into rumpdisk?

<iska>some VPS providers need it

<youpi>without actually trying it's hard to tell

<youpi>possibly it's just a matter of merely enabling it

<youpi>possibly there are bugs

<iska>so long it's bootable...

<iska>even read-only would be a win

<iska>in my eyes

<iska>also, -Og looks to be broken, st (LARBS) segfaults at around line 2141

<iska>glibc-related issue I think

<Pellescours>iska: For now we don’t even compile virtio when we compile rump lib

<iska>Pellescours ahhh icic

<iska>I thought rump didn't have VIO at all

<iska>why not compile it in?

<Pellescours>According to the debian patch, it fails at link

<luckyluke>Actually virtio should be there, I used the virtio block layer a bit a few years ago, but the irq integratiom needed some work

<luckyluke>Maybe with irqhelp it would work better

<iska>hmmm

<Pellescours>I will try compiling it to see

<youpi>iska: read-write is not much hard than read-only :)

<iska>youpi in terms of stability, it often is

<youpi>not really

<youpi>a disk driver either behaves fine or not

<youpi>be it reads or writes don't change much

<youpi>if it behaves badly, reads will be really at odds

<Pellescours>youpi: our netbsd version for rump is 10month ago old, Netbsd did a release the 4th august. Should I try to upgradet to that version (9.3) or to updgrade to latest dev?

<youpi>I'd say better take a released version

<youpi>to avoid getting hit by bugs

<Pellescours>iska: with virtio " multiple definition of `rumpns_virtio_cd'", it’s the same kind of issue I have than trying to compile rumpdisk with piixide and ahcisata

IRC channel logs

2022-09-22.log