> The Hurd has much better interfaces to get this info (the process message > port, and the Hurd libps library for example).
Right!!! BTW, nothing prevents you from collecting as much infos as possible from the Hurd servers (e.g. through libps) and present them in a hurdisch /proc-like FS. This is completely user-land and can be done by every user. This is what the Hurd is all about, after all ;) > > The list archive also shows post regarding a Linux binary emulation layer? Has > > there been any work on it? Any pointers? > > There are several layers. For example, we already use the same object > format (ELF). Then, we can provide the same glibc ABI (currently we don't, > though) in the future, which allows programs that only use glibc to access > the system's functionality to run directly on the Hurd without emulation. What would be _exactly_ needed to get a dynamically linked linux app run under the Hurd? I'm really curious here! > At a deeper level, we can redirect kernel traps (Linux syscalls) to a > special port that can then emulate them. The support for this is in Mach, > you just need to use it. This would usually happen by LD_PRELOADING a > special emulation library into the binary, which would set this up. Yes, that is true. Such an emulation library would be much easier to write than libmachemu+Lites from the original Helander paper, because it can rely on a working POSIX (Hurd-)glibc to do the dirty work: This emulation library would mostly redirect linux syscalls to glibc calls with tailored parameters. Some special cases will need to be taken care of, probably in something like a Linux-Kernel-Task, but for the vast majority of apps, simple redirection to Hurd-glibc would be IMHO all that is needed. -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
