IRC channel logs


back to list of logs

<damo22>solid_black: welcome back
<damo22>i think i have done gnumach io port locking, and pciaccess, but hurd part needs work and then to merge it needs a rebuild of glibc because of hurduser
<damo22>why cant libhurduser be part of the hurd package?
<solid_black>I don't think I understnad enough of this to do a review, but I'd still like to see the patch if it's available anywhere
<damo22>ok i can push to my repos
<solid_black>glibc needs to use the Hurd RPCs (and implement some, too), and glibc cannot depend on the Hurd package beucase the Hurd package depends on glibc
<damo22>lol ok
<solid_black>as things currently stand, glibc depends on the Hurd *headers* (including mig defs), but not any Hurd binaries
<solid_black>still, the cross build process is quite convoluted
<solid_black>I posted about it somwhere...
<damo22>its crazy
<jpoiret>the manual patching of the build system that's needed to bootstrap everything is a bit suboptimal
<damo22>what if you guys submit patches upstream to glibc to add a build target to copy the headers or whatever is needed
<damo22>solid_black: see{libpciaccess.git,gnumach.git} on fix-ioperm branches
<Arsen>fwiw, it is possible to get a header-only build:
<Arsen>and there's an install-headers target:
<solid_black>damo22: yes, glibc already has 'make install-headers' (except that you still need to build and install more stuff from it manually, see my thread I linked above)
<jpoiret>I'm thinking more about Hurd's header generation
<jpoiret>you can't even pass configure without a toolchain
<solid_black>to generate MIG headers, you need MIG, sure
<solid_black>and to build MIG you need Mach headers
<solid_black>and so on
<damo22>but mig is invoked with gcc -xE or whatever
<jpoiret>well here it shouldn't, otherwise you need very ugly hacks to make that work when bootstrapping
<solid_black>Arsen: for a second there I though you were talking about Gentoo on Hurd, and got excited :|
<Arsen>haven't had time to explore that yet
<Arsen>I'd like to do it one day (and I'm not alone) and I'd like to port glibc to yet another microkernel
<solid_black>I don't know much about Gentoo, but I now do have experience with cross-compiling Hurd (Mach, glibc, etc), so happy to help with Gentoo GNU/Hurd in any way I can
<solid_black>also if anyone wants to revive Arch Hurd, that'd be so cool too
<solid_black>we need more Hurd distros
<damo22>lets get the core working first with more drivers
<damo22>once it can boot on native hw im sure youll get people flocking in to help
<damo22>solid_black: im stuck with SMP, the locking in gnumach causes massive slowdown
<solid_black>the locking in gnumach is very inefficient, for one thing
<solid_black>like they lock/unlock just to set a single bit flag
<solid_black>which can be done with atomics
<solid_black>guess atomics weren't a thing when Mach was developed
<solid_black>(but then how did they implement locks?)
<damo22>double loop?
<solid_black>what's that?
<solid_black> 404s for me, am I looking in the wrong place?
<solid_black>/* Only ranges that are occupied by our task may be released */ return KERN_PROTECTION_FAILURE;
<solid_black>KERN_INVALID_ARGUMENT rather?
<damo22>#define _simple_lock(l) \
<damo22> ({ \
<damo22> while(_simple_lock_xchg_(l, 1)) \
<damo22> while (*(volatile int *)&(l)->lock_data) \
<damo22> cpu_pause(); \
<damo22> 0; \
<damo22> })
<solid_black>_simple_lock_xchg_ is the atomic there
<solid_black>also what? cpu_pause, so it's not even a sleeping lock?
<solid_black>no wonder everything's slow then
<damo22>cpu pause === asm("pause":::"memory")
<solid_black>yes, but it doesn't context-switch to another thread
<solid_black>i.e. it's a spinlock. not an actual sleeping lock
<solid_black>=> slow
<damo22>everything is a spinlock
<damo22>in mach
<solid_black>pci_device_hurd_open_device_io leaks io_perm if __i386_io_perm_modify fails
<solid_black>also you should not use the __ prefixed symbols from outside of glibc, they're glibc-private
<solid_black>so just i386_io_perm_modify
<damo22>solid_black: no it has problems if you define the same symbol
<damo22>we had a symbol clash in rumpdisk
<solid_black>yes, that is a problem
<damo22>its such a big library, we had to use the __ version
<solid_black>and glibc protects itself by using the __ symbols internally
<solid_black>but others don't get to
<damo22>too bad
<solid_black>you're still forgetting to check mach_port_deallocate return value
<solid_black>and I guess that of other rpcs too
<damo22>youre reading the code too literally
<damo22>i mean to look at the overall idea
<damo22>i havent finished
<solid_black>I don't understand enough about the I/O ports or the overall idea, so I can only nitpick on the implementation :)
<damo22>what dont you understand?
<damo22>io ports are from 0 to 0xffff
<damo22>they are attached to certain hardware
<damo22>assigned by the bios i think
<Arsen>not even
<Arsen>they're a hack on the 8086 to cheaply double the address space
<Arsen>it's literally just a memory IO bus with no instructions to access it outside of in/out
<Arsen>they're assigned as wired
<solid_black>interesting; that I didn't know
<damo22>Arsen: are you sure? i think coreboot can remap io ports to anything
<Arsen>on modern hw, possibly
<Arsen>Linux can to, as well as any other OS, via the MMIO
<damo22>so anyway
<damo22>you cant share the same io ports among more than one process or they will interfere with each others hardware access
<damo22>like one process might be doing an input or output while the other resets the device
<damo22>and all hell breaks loose
<damo22>i cant think of a way io ports could be shared among users
<damo22>Arsen: do you agree?
<Arsen>yeah, I don't think the devices on the other side would appreciate multiple writers
<solid_black>that all I mostly understand
<solid_black>and you want gnumach (and pci-arbiter?) to hand out I/O port ranges to whoever asks first
<solid_black>and deny getting the same range if it's already taken
<damo22>but it can be released
<damo22>if the device is no longer being used
<solid_black>is __pci_request_io_ports an RPC to pci-arbiter?
<solid_black>what are BARs?
<damo22>base address register
<solid_black>is that the same as an I/O port number?
<damo22>each pci device has up to 6 allocated memory io ranges
<damo22>bar is a number from 0-5
<solid_black>so like x86 segment registers?
<damo22>if you do lspci -vv
<damo22>you should see the ranges
<solid_black>so is_legacy is whether the port range has been requested directly from Mach, or from the pci-arbiter?
<solid_black>what does this actually influence?
<damo22>is_legacy is a libpciaccess artifact
<solid_black>sergey@hurdle:~$ lspci -vv
<solid_black>northing :|
<damo22>you need to be root
<damo22>i think
<solid_black>why doesn't it print an error then?
<damo22>dont know
<solid_black>oh yeah root works, pretty cool
<damo22>Region X: Memory at blah
<damo22>Region Y: I/O ports at blah
<damo22>these are mirrored at /servers/bus/pci/BUS/DEV/FUN/regionX
<damo22>in fact you can read/write the regions by opening the file nodes
<damo22>but io regions should not be exposed this way
<damo22>solid_black: why do we need to create directories and/or file nodes when installing translators? cant the caller create all the parent directories up to the node and then install the translator there?
<solid_black>damo22: what do you mean, in what context? are you talking about the new bootstrap process? just Hurd in general?
<solid_black>who's "we" and who's "the caller" in this context?
<solid_black>are you just asking why settrans(1) doesn't run mkdir -p itself?
<damo22>maybe yes
<solid_black>well, uh, it just doesn't
<solid_black>none of the similar Unix tools do
<solid_black>for instance touch(1) doesn't create the whole directory stack below the file
<solid_black>nor does ln(1), or cp(1), or mv(1), ...
<solid_black>not even mkdir(1), unless you say -p
<damo22>but i guess the new bootstrap thingy could though
<solid_black>it would probably still require an explicit mkdir in the boot script, but maybe not
<solid_black>I'm not decided yet
<damo22>it would be good if the boot script had nothing in it except what was strictly required
<damo22>so short in fact, that you could remember it and type it if needed
<damo22>that was one reason why i started writing that hurdhelper thing, to shorten the boot script
<solid_black>it is supposed to be very hackable, unlike the current boot process
<solid_black>but keeping the script short is not an explicit goal that I have
<solid_black>that being said, maybe we could imply the mkdir's indeed
<damo22>cant it just boot by default with a sane set of servers?
<solid_black>but what's a sane set?
<solid_black>and where do you boot from?
<solid_black>I guess if you specify root=wd0s1 or something on the kernel cmdline, we could work it out
<solid_black>but imagine it's a system that boots from nfs, over network
<damo22>i would consider that non-standard
<solid_black>how can you synthesize a sane configuration for that automatically?
<solid_black>or, I'd really like to get virtio + 9pfs working, to be able to use qemu's feature where it exposes a host directory as a 9p share
<solid_black>(speaking of which, do you happen to be hardware-savvy enough to hack on a virtiofs driver?)
<damo22>it used to work
<solid_black>and so it'd be nice to enable booting from 9pfs root
<solid_black>but again that's just not something that you can autodetect sanely
<damo22>virtio is supported in rump but something broke in the makefiles so we disabled it
<solid_black>as I undrestand it (but the usual disclaimer about me not being a hardware person applies), virtio is not a single device, it's more of a class of devices that are structured in a similar way
<solid_black>so you'd still have to write a driver for virtiofs specifically
<damo22>not really, the virtio disk driver can link to rumpdisk
<damo22>as a drop in replacement for ahci
<solid_black>it's not a disk driver that I'm talking about
<damo22>yes you boot qemu with a virtio disk
<damo22>and rumpdisk can detect it
<solid_black>no, I don't think you understand
<solid_black>this is not a virtio disk, as in /dev/vda
<solid_black>it's a different virtio device, more like a socket than a block device
<solid_black>that speaks the 9p protocol
<solid_black>and you can mount an fs from it
<damo22>why do you need that
<solid_black>beucase qemu has this neat feature (that I linked to above), where it exposes *hosts* directory as this virtio/9p mount to the guest
<solid_black>so you get shared folders
<solid_black>moreover, you could even try to *boot* from this 9p device as a root; this way you don't even have a separate disk for your Hurd VM at all, its contents are just a directory on the host
<solid_black>qemu has docs about doing this for linux:
<damo22>it is exposed as /dev/vda
<solid_black>no, that is a different thing
<damo22>see step 8 of the example
<damo22>-append "console=ttyS0 root=/dev/vda"
<solid_black>they're doing that to boot the installer (from disk)
<damo22>ah ok
<solid_black>-device virtio-9p-pci,id=fsRoot,fsdev=fsdev-fsRoot,mount_tag=fsRoot <--- this
<solid_black>-append 'root=fsRoot rw rootfstype=9p rootflags=trans=virtio,version=9p2000.L,msize=5000000,cache=mmap,posixacl console=ttyS0'
<solid_black>the Hurd version of this would be more like
<damo22>good luck i need to sleep
<solid_black>settrans /dev/virtio-9p /hurd/virtio-9p # fictional virtio-9p translator
<solid_black>settrans / /hurd/9pfs --aname fsRoot /dev/virtio-9p
<Guest60>sollid_black: you should try this with rump
<solid_black>Guest60: ah great, so it might just be a matter of enabling it in rump? cc damo22
<janneke>building gobject-introspection on Guix fails with this error
<janneke>(process:11919): GLib-ERROR **: 11:15:55.110: getauxval () failed: No such file or directory
<janneke>rign any bells, any ideas?
<Guest60>maybe it should go with rumpdisk, maybe there should be a rumpvirtio since it’s a different controller, like for rumpusbdisk.