IRC channel logs


back to list of 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
<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?
<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
<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
<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>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.