***Server sets mode: +nt
<damo22>i'm always in the wrong timezone <damo22>wleslie: ive been rebasing and trickling in smaller patches that can be safely merged into master, but there is still a problem to merge the lot <damo22>so far, to make the pcifs work, i had to hack netfs to allow installing a port with no uid=0 credentials <damo22>we need to solve that before i can merge a working disk driver <damo22>maybe we can make a new function netfs_make_super_protid() that only works during bootstrap? <damo22>so the only way to install a port with no cred is via that function and returns EOPNOTSUPP if its past bootstrapping time <damo22>and accepting a null dircred can be blocked after bootstrap too <wleslie>I'm not sure why netfs wants a port with root credentials <wleslie>if you have a port, you should be able to use it, right <damo22>but the user needs to be authenticated to run a netfs <damo22>currently it has no concept of a user before root fs is available <wleslie>seems kind of redundant though. if the user does not have the appropriate authority, they can't supply a mach host port, can they? or is that a different kind of host port? <damo22>ie if theres no "cred" you cant install a real port <damo22>i wonder if i can create a fake "struct iouser" <wleslie>so when we're starting netfs, we don't have a cred. what *do* we have? surely there's something that never gets as far as a user session. <wleslie>but probably yes, many things seem to make use of cred <damo22>netfs_startup calls : fsys_startup (bootstrap, flags, right, MACH_MSG_TYPE_COPY_SEND, &realnode); and gets a protid to a real underlying node <damo22>so i think it inherits the permissions of the underlying node <damo22>in my case, realnode == MACH_PORT_NULL at the time of bootstrapping <damo22>because the netfs pcifs IS a disjoint root filesystem <damo22>it needs to start before the disk does ***rekado_ is now known as rekado
<damo22>i dont understand how netfs_S_dir_lookup () is called with dircred = NULL, where does it get its parameters from? <wleslie>on comparison with libdiskfs/boot-start.c; I remain suspicious of needing a cred <damo22>i am looking there too, /* Create the port for current and root directory. */ <damo22>youpi: what is the realnode supposed to be when pcifs_startup returns, a port to what exactly? <damo22>im getting pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok <damo22>with the arbiter, rumpdisk, ext2fs and exec still running <damo22>i have a protid to the root port with a cred, what do i return as the realnode? <youpi>damo22: for realnode, see fsys_startup documentation hurd/fsys.defs: it is the node on which the translator is sitting in the parent filesystem. In your case you don't have a notion of realnode yet until ext2fs is started <youpi>so I'd say return a null port <damo22>pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok <damo22>Hurd bootstrap rumpdisk ext2fs: part:2:device:wd0: No such device or address <damo22>it does not seem to enumerate the pci devices <damo22>do i need to change the pci_control_port to be something to do with the protid of the root node in the pci filesystem? <damo22>i bet i need to call fsys_getroot <damo22>ok i think my problem is that there is no cred being passed in to the protid when netfs is looked up <damo22>i can create a cred, a peropen, and a protid manually, but it doesnt persist anywhere <damo22>is there a glibc variable or something where i can inject it in? <youpi>it's not related to glibc at all, it's attached to the port that you create in fsys_getroot <damo22>i keep getting hang with fsys_getroot :( <youpi>see netfs_S_fsys_getroot, it creates a cred, then creates a protid from that, and returns a right on it <youpi>and that's what the caller of fsys_getroot can use to make dir_lookup RPCs <damo22>what is the point of calling fsys_getroot in the arbiter startup? <damo22>don't i need to call it in rumpdisk and somehow use that port <youpi>? I wasn't talking about making the arbiter calling it <youpi>I was talking about rumpdisk calling it <youpi>so as to have a proper port on the pci-arbiter filesystem <youpi>yes but that doesn't return a port with proper creds etc. <youpi>that just returns the control port <youpi>but then on the control port you can call fsys_getroot <youpi>to get a port on the root node of the translator, with proper cred etc. <damo22>so where do i call fsys_getroot? in the libpciaccess? <damo22>so i device_open(pci) and then call fsys_getroot on it and use that port to access pci <damo22>why not put that in the device_open call <damo22>so the libpciaccess doesnt have to call fsys_getroot <youpi>that could be a way as well yes <youpi>that depends if at some point we might want to be able to use the control port for some reason <youpi>but possibly in the end since in the booted system we can use the FS node only, we'd have to go through an FS node anyway <damo22>i thought we only need a port to the root pci FS <youpi>but who knows what we'll want later on <youpi>I wasn't really thinking about hardware features, but rather bootstrap capabilities <youpi>like introducing yet other translators for whatever reason <damo22>i like device_open(pci) -> get a port to use directly otherwise its messy, what else would we use the control port for? <damo22>i dont think we should link libpciaccess to depend on libnetfs <youpi>control port: all the RPCs of fsys.defs <youpi>? there is no reason for libpciaccess to depend on libnetfs, I'm just saing to call fsys_getroot as an RPC, not as a function <youpi>don't confuse function call and RPC call <damo22>ok do you prefer fsys_getroot in libpciaccess or in device_open(pci)? <youpi>I don't know, I'm at work so I don't have time to think about it <youpi>I guess doing it in pci-arbiter's device_open will be simpler for now <youpi>for the qemu bug I'd say nobody will be able to work on it unless they have a bootable image that reproduces the issue ***Emulatorman__ is now known as Emulatorman