Aqcuiring full path to running process from outside the ?kernel

[Reko Turja]

----- Original Message ----- 
From: "Oliver Fromme" <olli at lurza.secnetix.de>
To: <freebsd-hackers at FreeBSD.ORG>; <reko.turja at liukuma.net>
Sent: Wednesday, August 23, 2006 2:40 PM
Subject: Re: Aqcuiring full path to running process from outside the 
?kernel


Oliver Fromme wrote:

> Another way would be to use /proc/$$/file (where $$ is the
> result from getpid()), but it only works when PROCFS is
> mounted on /proc, obviously.

Yep, and if I or whoever will get the OW into port collection, I think 
demanding /proc to be
mounted might be not that good idea - if the problem can be handled a 
way that vanilla BSD
understands.

> Finally, maybe you don't have to know the path at all.
> The kernel maintains a file descriptor of the executable.
> lsof(8) and fstat(1) display it (as "text" or "txt",
> repectively), so I assume there's a way to retrieve it
> from userland.  If you can get access to that file
> descriptor, you should be able to read data from the
> executable without having to know its path name.

I managed to do exactly that - the problem being for the moment is 
that all the other platforms OW
supports at the moment do fetch the path somehow. Linux uses /proc, 
DOS, NT and OS/2 whatever etc.
The logic in the resource fetching goes simplified like this: Ask the 
path for the current process from a
library function and with the path open a handle for the executable 
file and then fast forward into resource
part and fetch the strings needed. IMHO using the already available 
handle would be most elegant solution,
but that would mean major rewriting in the resource handling for the 
other platforms, hence for now I'll settle
just for trying to do this in manner compatible with existing code. 
(And of course something that's very simple
to achieve in FBSD can be a major pain for some other platform 
supported by Watcom toolchain...)

> The latter might even be the _only_ way to access the
> executable file, because someone might have unliked the
> directory entry right after starting it, so you cannot
> access it anymore by path name, but only by descriptor.

Or disappearing NFS mounts or other "fun things"

Still lot to do but at least now I have managed to tackle some of the 
biggest problems for bootstrapping
the toolchain, with lots of stuff copied from Linux build and 
requiring gnu make for the bootstrap...
Might be that I'm trying to climb a tree with my posterior in the 
fore, but the thing I'm trying to achieve
for now is getting the OW to bootstrap and build all the tools, then 
starting to change the makefiles from
gnu to bsd make and then see if anything can be done to clib with my 
skills or whether
that would be a job for more seasoned and BSD knowledgeable folks :) 
(There aren't that many makefiles for
gnu make as the bootstrap changes pretty soon using the wmake supplied 
with toolchain)

But enough of my rambling and thanks!

-Reko