IRC channel logs

<damo22>you need like a server version of |

<damo22>eg libfuse | sshfs

<Gooberpatrol66>damo22: there's a thing i found in incubator called nsmux which is kind of like | for translators

<gnucode>Gooberpatrol66: sort of. But it looks quite a bit of work. Try to use it, and you'll see that it is not quite finished yet...

<gnucode>but it certainly is a cool idea

<danmorg>hi

<solid_black>hello!

<damo22>hi

<solid_black>hi damo22

<damo22>i literally finished work now

<damo22>good timing

<solid_black>wdym about server version of pipe?

<solid_black>and I must admit I don't understand nsmux

<damo22>like, instead of servers attaching to nodes on the filesystem, you could specify how they connect with a |

<solid_black>but the server still has to be sitting on some node, no?

<damo22>maybe

<solid_black>unless indeed you want to create nodes dynamically, which is what I imagine nsmux does

<solid_black>bug again, I don't really see why you'd want that

<damo22>RPCs could be made easier

<solid_black>'settrans ~/meh /hurd/sshfs meh.server' looks very natural

<solid_black>as a user, you don't have to know or care that it uses libfuse

<damo22>ok

<solid_black>just as you don't care which translators use diskfs vs netfs vs trivfs now

<damo22>what should i work on this weekend?

<damo22>im kinda stuck with smp

<solid_black>keep working on smp, you seem to be doing a great job

<damo22>thanks, but i dont know what to do now

<solid_black>did you say your latest patch didn't work on x86_64 though?

<damo22>i havent tried 64 bit yet

<damo22>all my work is on 32 bit so far

<damo22>and i try to include the x86_64/ subtree when i make changes

<damo22>but i dont know if it works

<azert>I think that for active translators, having the possibility of starting them as a normal software, the way fuse do it, would be a nice thing

<solid_black>hi azert

<azert>Also settrans is obscure to me.. I think that should be a glibc function and not an app, but maybe I’m just confused

<azert>Hi solid_black

<solid_black>but that's basically what we have, no? fusermount ≈ settrans

<solid_black>what's unclear about settrans? (happy to explain!)

<solid_black>it is a command-line wrapper around glibc functions, that are thmelves wrappers over Mach RPCs

<solid_black>you can totally do the same thing from C

<azert>In Linux I often type sudo sshfs -o allow_other,default_permissions server

<azert>No fuseemount involved

<solid_black>that'll probably keep working on the Hurd too then

<azert>Nice!

<solid_black>but I imagine what you'd actually want is to set a static/passive translator record

<solid_black>for the server you often connect tp

<azert>Defaults to active in this case

<solid_black>yes, but like so that you don't have to mount it each time

<azert>Using settrans or a command line option in that case :)

<damo22>i found something interesting in the scheduler, it seems it is possible to schedule the same thread twice, ie, old_thread == new_thread

<damo22>there is a code path for that

<damo22>thread_invoke() can return TRUE if there is no continuation and the old_thread == new_thread

<damo22>wouldnt that be a failed handoff?

<solid_black>we don't have either O_DIRECT or O_SYNC, do we?

<solid_black>fuse-base bcachefs expectedly wants to access the underlying device as a file, and it opens it both with in without these two

<solid_black>fuse-based*

<solid_black>but we'd want it to use libstore, naturally

<gnucode>hello friends!

<gnucode>damo22: I have not done any benchmarking, but my T43 does seem faster thanks to your SMP work.

IRC channel logs

2023-09-28.log