IRC channel logs


back to list of logs

<curiosa>I'm looking into libtrivfs, do I understand it correctly that the library relies on the dynamic linker to find its hooks?
<curiosa>is it possible to override this?
<curiosa>without editing the symbol table programmatically
<curiosa>for which I am not aware of a standard way of doing it
<andrzejku>do you think hurd would be good for phones?
<kilobug>andrzejku: in term of modularity and security it could be, but it's far from being in a state where that would be possible, saddly
<andrzejku>kilobug, hmm I consider to help hurd but even don't know where to start
<youpi>andrzejku: there are URLs in the chan topic
<youpi>curiosa: please be more specific as to what "override" you would like to do
<youpi>since hooks are already a mean to allow overriding
<curiosa>yea sure
<youpi>(and beware of XY problem)
<curiosa>at this point, I am just trying to understand how hooks are getting called
<youpi>which hook for instance?
<curiosa>trivfs_S_io_read for instance
<youpi>$ git grep trivfs_open_hook .
<youpi>libtrivfs/fsys-getroot.c: if (! trivfs_open_hook)
<youpi>libtrivfs/fsys-getroot.c: err = (*trivfs_open_hook) (cntl, user, dotdot, flags, new_realnode,
<youpi>libtrivfs/priv.c:error_t (*trivfs_open_hook) (struct trivfs_control *fsys,
<youpi>libtrivfs/trivfs.h:extern error_t (*trivfs_open_hook) (struct trivfs_control *fsys,
<youpi>trans/magic.c: trivfs_open_hook = &magic_open;
<youpi>S_ functions are directly called from mig server demuxer
<curiosa>by default it seems to me that trivfs_S_io_read returns EOPNOTSUPP
<youpi>but you can define another one
<curiosa>how do the demuxer knows which api does you implement?
<youpi>ELF link namespace
<youpi>which says it's the program-defined function that goes first
<youpi>that being said it could be better to explicitly mark the libtrivfs-provided one weak, so that it can also come from another library without having to care about library load order
<youpi>like libnetfs does in libnetfs/iostubs.c
<curiosa>now I want to understand a bit better about what is the demuxer
<youpi>the source is generated at build time
<youpi>look for that
<youpi>it calls various trivfs server routines
<youpi>which are generated by mig
<curiosa>I found it, but that code doesn't tell me anything
<curiosa>mig works on def files, right
<youpi>as I said, it's generated at build time
<youpi>so look at the generated code
<youpi>the generated trivfs server routines
<youpi>it's all in there, just grep for them
<youpi>grep is a big hammer, but it's terribly efficient
<curiosa>great, I figured it out
<curiosa>it is quite elegant
<curiosa>at least for the user
<curiosa>any plans to reimplement mig as a perl script?
<youpi>what for?
<curiosa>to implement pluggable languages backends
<curiosa>just a nerdy tought
<youpi>I don't think we want to plug languages at that level
<youpi>because that'd mean having to reimplement libdiskfs/netfs/trivfs in that language
<youpi>and a lot of semantic hides there, we don't want to duplicate it
<youpi>(and thus the potential for bugs)
<curiosa>I didn't mean to reimplement those library
<curiosa>at which level would you pul language bindings?
<curiosa>in a way that they can use those libraries
<youpi>if you plug the language to mig, that means to can't reuse libdisk/net/trivfs
<youpi>by writing bindings for these libraries
<curiosa>but bindings cannot link itself to the ELF link namespaces
<youpi>bindings usually embed bits of C code
<curiosa>at least not all languages can do that
<curiosa>but then if you write code that goes there, you overrides all the defaults, right?
<curiosa>like embedded C code
<youpi>dlsym(RTLD_NEXT) can be used to call the original version
<gnu_srs1>Just a Q: What about extending mig to support structs? Is that already on the TODO list somewhere?
<youpi>it'd probably be useful
<curiosa>browsing around I fund this
<curiosa>I think it supports structs and unions but I don't know really if it was meant to be merged
<curiosa>he also did some work on gnumach and hurd in that direction, I dunno if you know anything about his work
<curiosa>might ease the 64bit transition
<curiosa>changing topics, are /proc/*/fd implementable?
<youpi>curiosa: with msg_get_dtable and such, probably
<Pellescours>damo22: can you update your git branch to add the biblio’s latests patch please? I want to test them but biblio is not here and I know he sent you them.
<curiosa>youpi: what is refport in msg_get_dtable ?
<curiosa>the task port ?
<youpi>see how it'd used in libshouldbeinlibc
<curiosa>yea, I guess it is proc server port, task port, output table
<curiosa>youpi I don't see any use of msg_get_dtable in libshouldbeinlibc
<curiosa>or anywhere else
<youpi>it's there
<youpi>$ git grep msg_get_dtable libshouldbeinlibc/
<youpi>libshouldbeinlibc/portinfo.c: msg_get_dtable (msgport, task, &dtable, &ndtable);
<curiosa>ok, it's not in the debian version (yet?)
<curiosa>I found it in savannah
<youpi>it's there in the git-portinfo.patch
<youpi>always grep with patches applied :)