***Server sets mode: +nt
<damo22>where is get_privileged_ports() defined? <damo22>doesnt seem to be in libc, hurd or gnumach <youpi>hurd/privports.c:__get_privileged_ports (mach_port_t *host_priv_ptr, <youpi>hurd/privports.c:weak_alias (__get_privileged_ports, get_privileged_ports) <jrtc27>codesearch.debian.net is your friend <damo22>i must have the wrong version of glibc source tree <jrtc27>yeah but that's only the debian directory <damo22>is hurd/ mostly upstreamed or are we maintaining it as patches in debian <jrtc27>it got upstreamed a year(?) or so ago <jrtc27>patches in debian are generally just things youpi has also upstreamed (or intends to) <damo22>mach_port_t _hurd_host_priv, _hurd_device_master; !!! now i know where these are <damo22>i didnt know you could use global variables from glibc as symbols in any program <youpi>glibc is a library like any other <jrtc27>what do you think errno is (used to) be? <jrtc27>(I say used to because if you have threads it needs to be thread-local, but in the good old days it was just a global in your libc...) <damo22>trivfs_S_fsys_getpriv needs to create a port in the trivfs_cntl_class and get a send right... i set the _hurd_host_priv to the port passed in on cli, what do i do with the send right? <damo22>is the dev_master supposed to be the send right? <youpi>a send right on a port from the trivfs bucket yes <youpi>just like you did for the bootstrap port passed to ext2fs <damo22>ok this is kind of making more sense now <damo22> /* Set the privileged port based on a command line arg previously set */ <youpi>Mmm, you may still want to call get_privileged_ports, so that _hurd_host_priv gets fetched from the proc server <youpi>(not useful for bootstrap, but couldbe useful for subhurd etc.) <youpi>damo22: where did you paste this from? <youpi>in fsys_getpriv you need to create a send right <youpi>just like __get_privileged_ports does <damo22>yeah i think i implemented what you said <damo22>in theory could it work if i tested it now? <youpi>in fsys_getpriv you need to create a send right <youpi>instead of the line you pasted <youpi>that's what I was talking about <youpi>that being said, you also need to change libdiskfs to call fsys_getpriv <youpi>since for now it assumes it's geting the device master port from the command line (bootstrap case) or from the proc server (non-bootstrap case) ***pie_[bnc] is now known as pie
***pie is now known as pie_
<damo22>i think libdiskfs already calls fsys_getpriv in diskfs_console_stdio() <damo22> err = get_privileged_ports (NULL, &dev); ***Shentino_ is now known as shentino
<youpi>damo22: that's for the boot process <youpi>ah, no that's indeed for all <youpi>alright that can be enough indeed <damo22>someone in #bootstrappable is writing a new posix-ish kernel that can be compiled with tcc to reduce the dependency on linux kernel and build deps... but i wonder why they dont use grub, it already has block support and fs drivers <damo22>id like to see GNU Mes running in grub <damo22>it could be scripted in such a way that the build recipe and initial minimal binary seed is burnt into flash <damo22>and when you boot into grub you could load a module and go through some steps to compile gcc and save it to a disk <shentino>can the mach microkernel make use of multicore? <youpi>shentino: please remember to read the faq <youpi>btw, I was wondering: shouldn't we drop /dev/ from what we have to specify to device_open in rump? I.e. add /dev/ automatically in rumpdisk <youpi>since devices will always be in /deV/ in the rump virtual FS <youpi>it would confuse people that things are called /dev/something when it's not actually necessarily appearing in /dev/ *youpi running helmut's bootstrap on the latest server at the lab, which has 1.5TB memory <youpi>(yes, it's a monster, though it has "only" 48 cores) <damo22>does my image show anything obvious about the boot sequence? <youpi>I guess mach_print here and there would help to know where it gets stuck :) <youpi>it seems the kernel detected sd0 and hd0, will your rump disk use yet another disk? <damo22>ahh i need to boot mach with no ahci <youpi>I was thinking that perhaps rumdisk should try to open_device("sd0") and if that suceeds, print a warning and abort <youpi>until we have really dropped the drivers from gnumach <youpi>(maybe have a --yes-i-know-what-i-am-doing flag to disable that check) <damo22>module /hurd/rumpdisk.static rumpdisk '${host-port}' '${fs-task}' '$(task-create)' '$(task-resume)' <damo22>is it correct to pass in the host port to rumpdisk? <damo22>i made it accept two command line args with argv[1] and argv[2] <youpi>yes, rumpdisk needs to have the host port <youpi>otherwise it can't call ioperm() <youpi>but you need to set it like libdiskfs/opts-std-startup.c: _hurd_host_priv = atoi (arg); break; <damo22>or is that something i wrote temporarily? my netdde points to it <youpi>there is, yes, in the incubator and debian package <youpi>we all did that kind of embarassing mistake :) <damo22>start rumpdisk: got a page fault, port->ip_sright > 0 assertion failed <youpi>that might be a bug that I fixed in gnumach master recently <youpi>but it basically means that one of your bootstrap task died <youpi>so you want to fix that actually <youpi>you can check in show all tasks <damo22>does setenv () cause inheritance of env vars to other threads? <youpi>yes, it's global to a process <damo22>i need to set RUMP_NCPU=1 and RUMP_VERBOSE=1 <rekado>I’m trying to add NFS support to the Guix hurd package. I’ve added libtirpc to provide the rpc headers, yet the check for a library providing an implementation of clnt_create fails. <rekado>I’m trying to add NFS support to the Guix hurd package. I’ve added libtirpc to provide the rpc headers, yet the check for a library providing an implementation of clnt_create fails. <rekado>Is the glibc supposed to be providing it? <rekado>(e.g. by building with --enable-obsolete-rpc?) <youpi>iirc that was removed from glibc at some point <rekado>or is there some other library that implements clnt_create? <damo22>youpi: rumpdisk got past detaching the pthread of the machdev_server thread and then i hit the srights error <youpi>damo22: probably it aborts somewhere in some RPC <rekado>yes, I added that for the rpc headers. <youpi>put prints inside the RPC stubs to make sure they enter/exit properly <rekado>maybe the check for clnt_create fails for unrelated reasons; will investigate <rekado>I’m looking forward to adding a bunch of Hurd VMs to ci.guix.gnu.org soon <janneke>this was one milestone i wanted to reach <janneke>now i'm blocked/looking at not seeing any incoming network connections <rekado>should we build just the dde branch or also dde_net from incubator.git…? <youpi>the dde branch build the libdde <youpi>that dde_net can then use to make linux drivers work <youpi>that being said, things should be working with the gnumach drivers already <damo22>qemu ..... -net nic,model=ne2k_pci <damo22> if (get_privileged_ports (&master_host, &master_device)) <damo22> err(1, "get_privileged_ports"); <janneke>damo22: yes, i have been using rtl8139 but also tried ne2k_pci <youpi>damo22: yes, that is expected to succeed <youpi>as in: the two _hurd_* variables should have been set before this gets called <damo22>really? but those variables are uninitialised i think <damo22>master_host and master_device in rump <youpi>your bootstrap code should be setting them <damo22>shouldnt i then be calling it with MACH_PORT_NULL values? <youpi>like libdiskfs/opts-std-startup.c: _hurd_host_priv = atoi (arg); break; and libdiskfs/opts-std-startup.c: _hurd_device_master = atoi (arg); break; <youpi>to be able to manipulate interrupts, allocate contiguous memory etc. <youpi>it really needs the mach kernel ports for those <damo22>yeah, but they should be set to zero initialised before calling get_privileged_ports () <damo22>theyre just global variables static mach_port_t master_host; <youpi>your bootstrap code should be setting them as the atoi lines do <youpi>I'm talking about the _hurd_device_master and _hurd_host_priv variables <damo22>im talking about the local variables in rump <youpi>yes, and I'm saying that the get_privileged_ports() call will succeeed, provided that you set _hurd_device_master and _hurd_host_priv before, in your bootstrap code <damo22>if they are uninitialised, they might have different values before it gets called and alter the behaviour? <youpi>so that the rump code will just get them and not care how they came here <youpi>(there must be a dumb misunderstanding somewhere) <youpi>master_host and master_device being uninitialized is fine, it's get_privileged_ports which will intialize them <youpi>from the _hurd_device_master and _hurd_host_priv <youpi>which you are supposed to set from the bootstrap code <janneke>damo22: note that outgoing connections work fine <youpi>(I don't need the source line number, I just need the variable name, it's just that your 'uninitialied' adjective was ambiguous: were you talking about master_device etc. or _hurd_device_master etc.) <youpi>damo22: oh but how is your qemu network configured? <youpi>did you set a host/guestfwd ? <janneke>guix build pulls all kinds of sources; also ssh to the host works <janneke>i'm doing: guix environment --ad-hoc qemu -- qemu-system-i386 -enable-kvm -drive file=geert.img,cache=writeback -m 2G -device rtl8139,netdev=net0 -netdev user,id=net0,hostfwd=tcp:127.0.0.1:2228-:22 <youpi>damo22: my point is: you are missing passing the host port to the rump process, in addition to the device port <youpi>janneke: no that's a hostfwd indeed <youpi>is the guest using 10.2.0.15 ? <youpi>did you use tcpdump to check what is coming in? <youpi>since you didn't specify in the hostfwd the IP of the guest <youpi>see qemu's doc: If guestaddr is not specified, its value is x.x.x.15 *janneke asks a RTFM on #hurd doh' <youpi>or rather specify the IP in the hostfwd <youpi>if there was some reason for using .2.77 <janneke>ah right, i don't know -- civodul picked it <damo22>it prints everything out except the last line <youpi>this is missing getting the device port from the command line <youpi>you need it, for rump to be able to get interrupts etc. <youpi>then as I said, put prints in the RPCs <youpi>also put prints in the machdev_server to make sure it initializes correctly <youpi>you should also keeping passing the host port to ext2fs <youpi>since IIRC you didn't make your fsys_getpriv return it? <youpi>so ext2fs wouldn't be able to get it that way <rekado>it really was just the test for clnt_create that doesn’t take into account LIBRARY_PATH. So libtirpc is sufficient. <rekado>There are some weird problems with the conflicting definitions between the Sun RPC headers and the Hurd files. <rekado>these redefinitions may be order-dependent as the errors change when building serially <janneke>youpi: thank you, it works beautifully <janneke>next thing to look at: => openpty: No such file or directory <janneke>i'm really happy with this, been bothering me for about a week (while fixing many others things) <janneke>hah, and without asking for a terminal: <janneke>lrwxrwxrwx 1 root 0 52 Jan 1 1970 build.sh -> /gnu/store/mwqb3sa6kg7gjvxhfm9yyc5gvsqmcw9m-build.sh <janneke>ah, and this works nicely: ssh root@geert /bin/sh -i <rekado>to get NFS to build I had to patch a few headers to make sure that rpc/types.h and rpc/xdr.h are included before rpc/pmap_prot.h; I also had to remove a few instances of #undef TRUE and #undef FALSE <youpi>gnu_srs1: why an exclamation mark? <youpi>don't be surprised that people don't tend to help you if you use exclamation marks rather than question marks ***dingenskirchen1 is now known as dingenskirchen
<rekado>janneke: I have no plans with NFS yet. I just thought it would be good to enable all features one by one, and NFS caught my eye first. <janneke>rekado: ah, right. i now have a VM that starts sshd and guix-daemon upon startup, using shepherd :-) <janneke>time to start figuring out how to start using the (gnu services) framework <gnu_srs1>youpi: Nice to know that you follow that. How can you have access to that info? Nevertheless, I would like to get a reply: yes/no/maybe/whatever <gnu_srs1>problem is that I would like to move forward, using more recent tarballs, get network working (dde from git seems to bet the clue), etc <youpi>I somehow got Cc-ed on the tracker, I don't know how <gnu_srs1>and again: I don't consider an exclamation mark as something non-appropriate, but you do. and maybe others... <youpi>sure, getting a reply would be nice, but "ping!" after only 5 days, in particular in these times, and on a easter week-end, is not the most efficient way to get somebody's likeliness to spend time on this <youpi>well, exclamation means exclamation, yes <youpi>which means ordering, and not requesting like a question mark would <gnu_srs1>yes, it is Easter, ending after tomorrow. Happy Easter to you all :) <gnu_srs1>I think it is a matter of culture, you are French, I'm Swedish, Ineiev unknown. <gnu_srs1>I can submit to github or gitlab, but prefer not to do that due to license issues ;) <youpi>I can't speak for all cultures, other people on this chan will say, but I believe you should try to adjust your level to what would be acceptable most widely <youpi>otherwise you run the risk of being unwelcome in most places <gnu_srs1>BTW: How to find the bug disabling e2fsck check of / fsysopts / --readonly does not work?? <youpi>diving into the sysv scripts? <gnu_srs1>So the problem is with sysv*? Even starting the image with rescue/whatever mode does not work? <youpi>I don't know, but most probably it's sysv* <youpi>since it's sysv which calls e2fsck etc. <youpi>look in the sysvinit code, check what calls fsck, pu tprints there, see that they show up, and that'll confirm <user_oreloznog>Happy Easter too gnu_srs1, rekado, youpi, janneke and all of you :-) ***Emulatorman_ is now known as Emulatorman
