IRC channel logs


back to list of logs

***Server sets mode: +nt
<damo22>where is get_privileged_ports() defined?
<damo22>doesnt seem to be in libc, hurd or gnumach
<youpi>it's in glibc
<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>glibc hurd/privports.c
<jrtc27> is your friend
<damo22>i must have the wrong version of glibc source tree
<damo22> ?
<jrtc27>yeah but that's only the debian directory
<jrtc27>the actual upstream source lives at
<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>why not?
<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 */
<damo22> *host_priv = _hurd_host_priv;
<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
<youpi>so, what I said :)
<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>this is what I said
<damo22>in libdiskfs?
<youpi>no in lib machdev
<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>like I mentioned earlier
<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_
<youpi>(in diskfs_init_main() )
*youpi off
<damo22>see ya
<damo22>i think libdiskfs already calls fsys_getpriv in diskfs_console_stdio()
<damo22> if (diskfs_boot_filesystem ())
<damo22> _diskfs_boot_privports ();
<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>not yet
<youpi>but it used to support SMP
<youpi>shentino: please remember to read the faq
<damo22>getting closer
<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>(the userland /dev/)
<damo22>yes we can do that
*youpi running helmut's bootstrap on the latest server at the lab, which has 1.5TB memory
<youpi>it's blazingly fast
<youpi>(yes, it's a monster, though it has "only" 48 cores)
<damo22>does my image show anything obvious about the boot sequence?
<damo22>is it almost working?
<youpi>it looks correct
<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>thats probably a good idea
<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 wrote it, i should know lol
<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>yeah i did that
<damo22>is there libmachdevdde now?
<damo22>or is that something i wrote temporarily? my netdde points to it
<youpi>there is, yes, in the incubator and debian package
<damo22>haha i deleted the .so
<damo22>restored from my cache
<damo22>ahh the args are backward
<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
<damo22>i dropped to db>
<youpi>you can check in show all tasks
<damo22>gnumach, ext2fs, exec
<youpi>so your rumpdisk died
<damo22>no rumpdisk
<damo22>ok coool
<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
<damo22>for /hurd/rumpdisk.static
<damo22>so in main i used setenv()
<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>rekado: there is a libtirpc
<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
<damo22>^ Thanks
<rekado>maybe the check for clnt_create fails for unrelated reasons; will investigate
<janneke>guix VM builds its first true package:
<youpi>yay :D
<rekado>I’m looking forward to adding a bunch of Hurd VMs to soon
<janneke>rekado: \o/
<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>did you try ne2k_pci
<damo22>qemu ..... -net nic,model=ne2k_pci
<damo22>in librump we have:
<damo22> if (get_privileged_ports (&master_host, &master_device))
<damo22> err(1, "get_privileged_ports");
<damo22> pci_system_init ();
<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>no, rump really needs them
<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>in librump
<youpi>? no
<youpi>why shoudl they?
<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>and not touch them
<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>what be uninitialized?
<damo22>let me find the line
<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
<damo22>janneke: ohh
<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>youpi: sure
<youpi>how so?
<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:
<janneke>eh wait, guestfwd?
<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 ?
<youpi>did you use tcpdump to check what is coming in?
<janneke>no, we're using
<youpi>then that's no wonder
<janneke>no, i only tried netcat until now
<youpi>since you didn't specify in the hostfwd the IP of the guest
<janneke>(after sshd -ddd kept silent)
<youpi>see qemu's doc: If guestaddr is not specified, its value is x.x.x.15
*janneke asks a RTFM on #hurd doh'
<janneke>gonne try right away!
<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>youpi: this is my main.c
<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.
<damo22>ahh device_port
<youpi>you need *both*
<damo22>i added _hurd_device_master = atoi (argv[3]); and this is my grub config
<damo22>i get the same failure
<youpi>then as I said, put prints in the RPCs
<youpi>to check what happens
<youpi>also put prints in the machdev_server to make sure it initializes correctly
<damo22>ok thanks, sleeping
<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>ssh root@geert ls -l /root
<janneke>total 0
<janneke>lrwxrwxrwx 1 root 0 52 Jan 1 1970 -> /gnu/store/
<janneke>ah, and this works nicely: ssh root@geert /bin/sh -i
<janneke>doing: MAKEDEV ptyp0
<janneke>gives a terminal
<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
<rekado>but it eventually built.
<janneke>NFS -- you have plans?
<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
<gnu_srs1>fixing all FIXMEs, 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 :-)
<gnu_srs1>user_oreloznog: TKS :)
***Emulatorman_ is now known as Emulatorman