IRC channel logs

***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>"hwdev"

<damo22> /dev could be a mountpoint for hwdev on /

<damo22>but hwdev can still be accessed before / is mouted

<damo22>mounted*

<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

<almuhs>this https://lists.gnu.org/archive/html/bug-hurd/2018-12/msg00050.html

<youpi>that one was for using the rump disk support

<youpi>FS support is a different thing

IRC channel logs

2020-06-21.log