***Server sets mode: +nt
***Server sets mode: +nt
***pisculic1i is now known as piculichi
***wleslie is now known as verte
***verte is now known as wleslie
***pie_[bnc] is now known as pie_
***pie_ is now known as pie__
***pie__ is now known as pi^e
***pi^e is now known as pi^e_
***pi^e_ is now known as pie_[bnc]
<damo22>youpi: do i need to resume the tasks in the code with task_resume() <damo22>im confused between a task_t and a mach_port_t <damo22>do i need a port "right" to set the special port? <damo22>or does setting the special port return a right <youpi>damo22: (resume): yes, since only pci-arbiter will get resumed by the kernel, it has to resume the rump translator, and similarly between rump and ext2fs <youpi>damo22: in userland a task_t _is_ a mach_port_t :) <youpi>damo22: see what happens with diskfs_exec_server_task <youpi>it is simply gotten from the command line's exec-server-task parameter <youpi>what happens when we write --exec-server-task='${exec-task}' is that the kernel creates a port right for the ext2fs task, and passes the number of the port right on its command line <youpi>task_set_special_port (diskfs_exec_server_task, TASK_BOOTSTRAP_PORT, right); can then be called, nothing more to do on that port <youpi>the "right" in that call however needs to be created, yes, just like start_execserver does it <damo22>youpi: another question, if i call resume_disk_task() when the disk_server_task != TASK_NULL does the bootstrap port need to be set to disk_server_task so "bootstrap" can be used normally? <damo22>ie, how does the startup of the server work if there is a custom "bootstrap"? <damo22>eg, do i set bootstrap = disk_server_task; so i can call this: <damo22> /* Create the PCI filesystem */ <damo22> err = init_file_system (netfs_startup (bootstrap, O_READ), fs); <youpi>damo22: I don't have the time to investigate, but that'd rather be like libdiskfs's boot-start.c <youpi>diskfs_S_fsys_initdiskfs_S_fsys_initdiskfs_S_fsys_init <youpi>which looks at diskfs_exec_server_task <youpi>and if not NULL, be fine with the boottrap port being null <youpi>I know that netfs_startup will error out in that case <youpi>it's the caller which should handle the case when bootstrap is null <youpi>so that function should just silently not call fsys_startup, probably <youpi>I don't understand why you create a port class/bucket <youpi>shouldn't you already have something like that? <youpi>ah, no, because it's opened from the FS <youpi>and here rump-disk would open pci-arbiter as a device, is that so? <youpi>though it's a bit of a stretch <youpi>I mean, pci-arbiter can still expose its FS, rump just needs to have the port of the / of that FS <youpi>and use that instead of /servers/pci to lookup files <youpi>(with file_name_lookup_under) <damo22>it seems like stretching it to include things irrelevant just to chain them together <youpi>yes, pci-arbiter should just need to pass a send right to the root of its FS <youpi>also, init_file_system needs to be fixed to accept not having an underlying node <youpi>to create the right to be passed to rump for opening pci arbiter files, that'd be something like what libnetfs/fsys-getroot.c does <youpi>create a newpi for the root of the libnetfs FS <youpi>and use ports_get_right() to make a right send to it <youpi>damo22: I would say, though, that you should first work on plumbing rump with ext2fs <youpi>letting rump use the x86 backend of libpciaccess <youpi>to avoid having to get everything altogether before getting anything work <youpi>rather start with a simpler picture <youpi>(and a simpler case, because for rump, there is no question of how to make rump disks show up in /dev, that'll work just like mach ports, through the bootstrap port chaining we talked about) <youpi>for the pci-arbiter case it's a bit more complex: <youpi>either we'd have to make pci-arbiter attach itself to a node of the FS of ext2fs after that is started (which looks hairy) <youpi>or we'd make pci-arbiter expose its FS as a device to be obtained through device_open on the bootstrap port <youpi>(remember that RPCs are not tied to know you obtain a port, usually you use device_* RPCs on a node obtained with device_open, but there is no obligation so) <youpi>and we'd let pci-arbiter get started again, settrans-ed to /servers/pci, it would first try to device_open("pci-arbiter") on the bootstrap port, and if successful, just return the obtained port (similarly to netddde's hand-off to gnumach network device drivers), and otherwise start as it does currently <youpi>(but again, better skip that part for now and let rump use the x86 backend, understand and implement how to plumb it with ext2fs, and things will be more clear for the pci-arbiter case) ***Emulatorman_ is now known as Emulatorman
***DNS777 is now known as DNS