From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 20 18:28:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE6BD16A4DE for ; Sun, 20 Aug 2006 18:28:10 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 861FC43D86 for ; Sun, 20 Aug 2006 18:28:02 +0000 (GMT) (envelope-from reko.turja@liukuma.net) Received: from moria.endor.swagman.org ([213.113.4.185] [213.113.4.185]) by mxfep02.bredband.com with ESMTP id <20060820182801.SJOE11843.mxfep02.bredband.com@moria.endor.swagman.org> for ; Sun, 20 Aug 2006 20:28:01 +0200 Received: from rivendell (rivendell.endor.swagman.org [192.168.10.10]) by moria.endor.swagman.org (Postfix) with SMTP id 0D2D0C for ; Sun, 20 Aug 2006 21:27:59 +0300 (EEST) Message-ID: <017601c6c486$6477c370$0a0aa8c0@rivendell> From: "Reko Turja" To: Date: Sun, 20 Aug 2006 21:28:10 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Subject: Aqcuiring full path to running process from outside the kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 18:28:11 -0000 I've been playing with Open Watcom for a bit in FreeBSD and for a while there's been one stumblim block for further advancement. Watcom uses a method for storing program messages etc. where these messages are stored as a "resource file" inside the executable itself. As the commands are usually invoked without the canonical path, the tools cannot find the resource portion stored inside. This far I've been looking for some solutions from which none seem to work too well. vn_fullpath (9) is running only inside kernel I think, and with the approach using kvm_openfiles and kvm_getprocs I can only get the command without the path (there are vnode etc. structures inside the kinfo_proc structure, but those seem to be unavailable from user space). Of course /proc might help in here, but I rather kept the code compilable on very vanilla system. Any pointers on how to proceed would be welcome. -Reko