<almuhs>I've almost ready the cpus detection and enumeration patch ***Server sets mode: +nt
***rekado_ is now known as rekado
<damo22>youpi: can you see an advantage of having device nodes separate from / ? if they werent attached to root fs you could have some place to attach the translators for mounting / <damo22>otherwise, i cant see a way forward to cleanly boot the system <damo22>i mean, with rump and pci-arbiter and whatever else is required <damo22>also, with filesystems that dont support xattrs you need a way to attach a translator <damo22>maybe they should all live in a ramdisk? <jrtc27>[09:19:01] <youpi> just to answer damo (it's really unfortunate we're always offset like this): that's what device_open() on a master port is for, and the boostrap master port can be used for that <jrtc27>[09:19:31] <youpi> the idea is that translators started before the FS can expose themselves through a name on the master port <jrtc27>[09:19:45] <youpi> and that can be exposed later in the FS through a simple device node <damo22>ah thanks i missed that in my log <jrtc27>yeah you'd left about 2h before that <damo22>i think its a bug with the management engine missing <damo22>so if i understand correctly: there can be multiple "master" ports, and the "bootstrap master" port is the first one that is available for booting the system. But that means gnumach's master device port conflicts with rumpdisk's master device port, and the current fallback mechanism is flaky at best, it tries to open the device name on rumpdisk first, and if it fails it opens gnumach instead. It will get complex as we add more drivers <damo22>or two instances of rumpdisk for 2 different AHCI controllers, for example <youpi>not multiple "master" ports, a chain of master ports <youpi>the modules booted by grub will start one after the other, playing the bootstrap dance you have already set up between rumpdisk and ext2fs <youpi>so that the bootstrap is done in the proper order: pci-arbiter, rumpdisk, ext2fs <youpi>there can be conflicts if two translators use the same device name, sure, but it just needs different device names <youpi>if several instances of rumpdisk are run that poses problem, sure, but for bootstrap you won't need several instances, you only need the one for the / ext2fs <damo22>but why should "time" be attempted to be opened on rumpdisk master port? <youpi>how the different instances of rumpdisk show up in /Dev can then be handled in userspace with setting up nodes in /dev <youpi>it could be a userland translator too <youpi>if time was to be managed somehow that is not in the kernel <damo22>how do i pass the host priv port to ext2fs if ive already given it to rumpdisk? <damo22>currently that part is broken i think because userspace has no i/o access with ioperm() <youpi>rumpdisk passes it over to ext2fs <damo22>i am calling get_privileged_ports (host_priv, NULL); <damo22>i suppose that pulls it from libc variable <youpi>that should be properly getting it from libc yes <youpi>perhaps make sure that that one is properly set <youpi>mach_print can only take a char* but that's the idea yes <youpi>Mmm, checking the ioperm() function... <youpi>it's not using the host priv port, but the device master port <youpi>so the bootstrap translators would actually need to handle i386_io_perm* and forward to their next superior device master port <youpi>only the io_perm_create call, actually <damo22>that is probably the cause of the crash in /hurd/console <damo22>so if i fix that and the startup thing for reboot, everything except netdde will work <youpi>console needs it to access vga yes <youpi>netdde will only additionally need the irq and contiguous allocation patches in gnumach <damo22>i have that already patched locally but i think its broken because pci-arbiter is non-functional when rumpdisk has libpciaccess.a baked in <damo22>im using the x86 method for pci access <damo22>but /servers/bus/pci cannot be accessed with no / <youpi>ah, you mean the question is now getting access to the pci arbiter from userland <youpi>pci-arbiter could be exposed as a device name in the master device port <youpi>and the userland pci-arbiter running on /server/bus/pci can try to open that <youpi>just like netdde tries to open eth0 to check whether there are already device drivers in gnumach, in which case it shouldn't handle network cards <damo22>pci-arbiter needs to have a device name? <damo22>as in it will implement the mach device interface? <youpi>in the end, when we know for sure that pci-arbiter is run as a bootstrap translator, we can make /server/bus/pci a mere device node <youpi>so it can be opened via device_open, yes <youpi>it doesn't need to implement the whole of the device interface, there is no need for device_read etc. <youpi>it just needs to answer device_open, and return a port on which the pci protocol can work <damo22>so in the bigger picture, what list of translators do we need to boot a general system and mount / <youpi>not much more than we almost already have <youpi>with a / on nfs, it'd be pci-arbiter, netdde, pfinet, nfs <youpi>does rumpnet provide both the network driver and the tcp/ip stack? <damo22>i think it will be easier to work on other drivers once disk is solved <youpi>you'll need to add makefile rules to create the mach_i386 server <youpi>that will call S_io_perm_create, and that you'll have to call in the demuxer call <damo22>in gnumach i386/include/mach/i386/mach_i386.defs <youpi>that's the .defs file for it yes <damo22>is there a non-i386 specific one? <youpi>I actually don't remember another arch with such io-port operations <youpi>I'm not even sure ia64 had it <damo22>so the server implementation will be S_i386_io_perm_create() ? <youpi>yes, unless you request another prefix <damo22>i cant write code tonight im too tired but i have written a todo for myself