IRC channel logs

<curiosa>I'm looking into libtrivfs, do I understand it correctly that the library relies on the dynamic linker to find its hooks?

<youpi>yes

<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>hello

<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?

<youpi>e.g.

<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>yes

<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>clear

<curiosa>now I want to understand a bit better about what is the demuxer

<youpi>the source is generated at build time

<youpi>trivfs_demuxer

<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

<curiosa>ok

<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 https://github.com/flavioc/mig

<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 https://github.com/flavioc/gnumach/commits/cmig https://github.com/flavioc/hurd/commits/cmig

<curiosa> https://lists.gnu.org/archive/html/bug-hurd/2016-04/msg00106.html

<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>yes

<youpi>see how it'd used in libshouldbeinlibc

<curiosa>yea, I guess it is proc server port, task port, output table

<curiosa>ok

<curiosa>youpi I don't see any use of msg_get_dtable in libshouldbeinlibc

<curiosa>or anywhere else

<youpi>?

<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 :)

IRC channel logs

2022-02-04.log