IRC channel logs

2025-07-27.log

back to list of logs

<diegonc>p4r4D0xum, I could reproduce the issue. but there are a los of errors regarding cd0 :/
<diegonc>*couldn't
<azert>Reading Milos mail in the mailing list made me realize that the Hurd doesn’t have a vfs api
<azert>An official api to work on inodes and superblocks and such
<azert>there is diskfs, but that is not exposed as rpc to privileged process (eg the way the Linux vfs api is exposed to kernel modules)
<azert>Should it be?
<damo22>is it not filesystem dependent?
<damo22>like what kind of metadata can be written
<azert>some Linux kernel module does operate on inodes directly
<azert>things like SELinux
<azert>eCryptfs
<azert>but it’s not clear whether they really need to and couldn’t be implemented in other ways
<azert>damo22: I think that on Linux filesystems are forced to align to the vfs api
<azert>so it’s not fs dependent
<azert>while on the Hurd, for sure it is
<azert>how would you hook up SELinux on the Hurd?
<azert>maybe as a library that hooks into libdiskfs
<azert>Then what about NSF, for instance?
<azert>one can see this as a feature, like you cannot “force” SELinux on every user
<azert>anyhow I was mentioning this for a simple reason
<azert>what if they will?!? What if one day there will be SELinux-like enabled libdiskfs that will hook in to work directly on inodes. Will that break the Milos journaling format? Or is it extensible and flexible enough?
<azert>let’s say you make it extensible, does it mean that you cannot use it to move data?
<azert>I think that there is a reason why Linux journaling normally happens below the vfs level
<azert>that is to allow external kernel modules to act on inodes without breaking the on disk format
<damo22>i think the filesystem is responsible for inodes but they could use a common api i suppose, although i dont think its a good idea to operate directly on inodes unless you are the filesystem
<azert>on the Hurd, Yes! On Linux it is totally fine to operate on the inodes
<azert>one has to wonder what is the common denominator, and the one of the Hurd might be a tad high level
<azert>the risk is to end up with hundreds of file systems each incompatible to each other
<azert>which is funny, considering how hard it is to maintain o e
<azert>one