IRC channel logs


back to list of 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
<Zopolis4>one that trigger on hurd when they should only trigger on apple
<youpi>that's more probably looking for an ifdef for macos
<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
<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
<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>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>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
<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>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>thus you pack
<damo22>bitfields are not good either
<damo22>they are dependent on host order
<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
<youpi>I have to say the gcc behavior makes more sense to me here
<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
<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