IRC channel logs


back to list of logs

***Server sets mode: +nt
<damo22>CDROM mounts
<damo22>at boot time
<damo22>(in userspace)
<damo22>gnu_srs1: hey
<damo22>any hurd peeps around?
<damo22>i'm always in the wrong timezone
<wleslie>very cool
<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> this is a working branch with the hack
<wleslie>thanks, was just about to ask (:
<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
<damo22>but netfs expects a "protid"
<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> this is how netfs protects the system from unauthorised use of netfs
<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>that the netfs is attached to
<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
<wleslie>it requires the host_priv port
<damo22>i am looking there too, /* Create the port for current and root directory. */
<damo22>maybe i can do that
<damo22>and call fsys_getroot properly
<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>how do i fix that?
<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
<youpi>hang where?
<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>with rood access etc.
<damo22>i see
<damo22>but i am calling device_open
<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?
<youpi>possibly, yes
<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
<damo22>that would be cleaner i think
<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>probably yes
<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
<damo22>oh sorry
<youpi>I guess doing it in pci-arbiter's device_open will be simpler for now
<damo22>we can move it later
<damo22>IT BOOTS
<damo22>no netfs hacks
<youpi>damo22: yay
<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
<damo22>ok have pushed new patches
<wleslie>well done, have a good night
<gnu_srs1>damo22: congrats!! :)
***Emulatorman__ is now known as Emulatorman
<damo22>thanks youpi for fast review