IRC channel logs

2022-05-16.log

back to list of logs

<Curiosa>Hello, I have a silly question.
<Curiosa>can a translator show up as a shared library on dlopen, thus providing some kind of vDSO to the user. And then use these exported functions to access the other RPCs of the translator?
<Curiosa>would this be an anti-pattern in your opinion?
<youpi>you could check out about migrating threads
<youpi>AIUI that's the kind of thing you are thinking of
<youpi>("migrating threads" with hurd keywords along it, to find what was discussed some time ago about it in the context of the Hurd)
<Curiosa>I think migrating threads would also switch the virtual address space, while this wouldn't
<Curiosa>of course it's a sexy model the one where threads migrates like they do in linux from userspace to kernel space but this time also in other user-kind address spaces
<Curiosa>in theory a task could even have zero threads and just serves RPCs, not sure about this in GNUmach but in theory..
<luckyluke>is there a way in gnumach to make the scheduling as much deterministic as possible? e.g. completely disable preemption
<luckyluke>I'm having difficulties tracing a bug that happens long after exec/ext2fs are running, around the time /hurd/startup is launched...
<luckyluke>in this case I have a general protection failure, apparently something is corrupting CS, but the point is it doesn't happen always at the same point...
<luckyluke>Curiosa: what would be the difference/advantage of using a translator instead of a regular shared library?
<Curiosa>Hi luckyluke, how is it going your 64bit port?
<Curiosa>Im not sure what I propose would be as much an advantage as more kind of an original solution to problems that are solved by other means
<Curiosa>For instance, by upgrading the translatior you also upgrade.
<Curiosa>a related api
<Curiosa>Cool could be the generalization of shared libraries
<Curiosa>Where you could separate a kernel part maintaining state in its own address space from a user part common to all users in the vdso
<Curiosa>All in the same binary
<Curiosa>Also using dlopen to access the api seems straightforward in comparison static linking
<Curiosa>The tought
<Curiosa>in fact translators could be akin to dos resident programs but secure and protected memory aware
<Curiosa>At least this specific class of translators
<Curiosa>Also speed: vDSO combined with shared memory might save quite some RPCs
<Curiosa>To sum up, a translator of this kind could provide four things, each of them optional: a state in a protected address space, specific shared pages from that space to user programs, some code running in the background in that address space (eg driving a device), a vdso exported to user programs.
<Curiosa>Only if question is if it is worth it to put the fourth thing together with the first three
<Curiosa>and if the third thing is really often necessary