IRC channel logs


back to list of logs

***Server sets mode: +nt
***Server sets mode: +nt
<damo22>jrtc27: thanks for info
<damo22>i am hesitant to start a new conversation upstream about introducing an api to select backend because they still havent replied to my latest PR/issue
<damo22>i have rumpdisk booting root fs with libpciaccess.a linked to it but im not sure how pci-arbiter can be part of the boot process without a root filesystem it seems very tricky dance to make
<damo22>i think it could make sense for gnumach to host a "device" ramdisk with just a bunch of nodes we can attach translators to
<damo22>just for the purpose of bootstrapping the system
<damo22>we could call it bootfs
<damo22>in fact, why do the underlying nodes that translators attach to have to be part of /
<damo22>why cant there be two roots
<damo22>one for translators and one for files
<damo22>translator nodes
<damo22>if these two were separated, you could unmount /
<damo22>well almost
<damo22> /dev could be a mountpoint for hwdev on /
<damo22>but hwdev can still be accessed before / is mouted
<jrtc27>because every file is a translator on hurd
<jrtc27>files are implemented by being translators for your underlying file system
<jrtc27>at a high level
<damo22>jrtc27: can you see an advantage of having device nodes separate from /
<damo22>i cant think of a better way to boot the system
<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
<youpi>the idea is that translators started before the FS can expose themselves through a name on the master port
<youpi>and that can be exposed later in the FS through a simple device node
***roptat_ is now known as roptat
<cbaines>Should df work on the hurd?
<cbaines>I get: df: cannot read table of mounted file systems: No such file or directory
<cbaines>Ah, df -h / gives me the information I was looking for :)
<almuhs>hi. A quick question. Once paging is configured, what is the higher address which is possible to access using phystokv()?
<janneke>attempting to boot with a root filesystem that is a linux (ext4) filesystem, i get:
<janneke>start ext2fs: ext2fs: device:hd0s1: panic: get_hypermetadata: could not mount because of unsupported optional features (0x2c0)
<janneke>which "optional feature" would 0x2c0 be?
<janneke>hmm, 2c0 could be "ext3"?
<jrtc27>it'll be a bunch of features
<jrtc27>hurd is pure ext2
<janneke>yes, and -o hurd -O ext_attr
<janneke>and ext4 is supposed to be dir_index,has_journal,uninit_bg
<janneke>which we'll have to unset
<janneke>i'm wondering what 0x2c0 is, though
<janneke>bah, the extent flag cannot be reset
<janneke>it seems i need to really create a new file system
<almuhs>janneke: maybe you can contribute to add support to ext3 and ext4
<youpi>I'd say better work on adding support for the rump filesystem implementation
<almuhs>yes, I remember that latest year someone send a patch to ease the port using rump
<youpi>that one was for using the rump disk support
<youpi>FS support is a different thing