From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 19:23:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF25816A46D for ; Tue, 3 Jul 2007 19:23:09 +0000 (UTC) (envelope-from erenerdemli@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5A113C45A for ; Tue, 3 Jul 2007 19:23:09 +0000 (UTC) (envelope-from erenerdemli@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so3896769pyb for ; Tue, 03 Jul 2007 12:23:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Ekf65V1B3Ejl4KpmiUr/3np6xiQkwg+IxuQvtLfztuSnsKzHxVz9TGpq7UGT6A0MGqxDmcPaIfSEkYz/1QKDw39YP4fnzoi9Ht64kRlB18AGML7l9PESeQlW40tbfAVF0DKvUEiMDpy6u/acOIL1AmhJH0aDeLJutqvwrECpS6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jdR4ctgNnToWtEyo7YEFr81M8rOlzlK/VelkF0pBjI0tH2CZowdYR/SKQ8ZdHu6nS3sWbzqM4AIbtLYFX0Pf1cdQKqJSA5f9L+oAzxjTQwKlLM6PMeE+D0TPMYnf75/WFfViXSPPl1sPDojJq8PqFIzDvdh9a1VhEY8mTmdCw7k= Received: by 10.65.214.2 with SMTP id r2mr3433859qbq.1183490587435; Tue, 03 Jul 2007 12:23:07 -0700 (PDT) Received: by 10.64.193.16 with HTTP; Tue, 3 Jul 2007 12:23:07 -0700 (PDT) Message-ID: Date: Tue, 3 Jul 2007 19:23:07 +0000 From: "Eren Erdemli" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86sl86bwa5.fsf@dwp.des.no> MIME-Version: 1.0 References: <86sl86bwa5.fsf@dwp.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: getcwd in kernel space X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2007 19:23:09 -0000 Hello I am not actually replacing the mkdir instead I am trying to get the change= s happened in directories such as FAM(Fiile Alteration Monitor), so you are right about the of the parent directory in which case it will be cwd. I have tried vn_fullpath() however it is not as reliable as it needs to be since once an rmdir command executes on the folder vn_fullpath() returns ENOTDIR. So will a namei lookup get me the path name of the parent. Basically I wil= l need to perform this in open, link unlink also. My understanding is that namei lookup will return = a vnode am I wrong ??? Thanks On 7/2/07, Dag-Erling Sm=F8rgrav wrote: > > "Eren Erdemli" writes: > > I am new to freebsd programing and I am trying to get the current > > working directory of the curthread. > > curthread->td_proc->p_fd->fd_cdir is a pointer to the directory's vnode. > > > I have hook on to the sys calls and redirected the mkdir > > > > my_mkdir(struct thread *p, (void*) uap) > > { > > mkdir_args =3D ..................... > > ........ > > getCWD()??????????? > > } > > > > the given path in the args is relative to the current path if not > supplied > > fully. So who would I get the path of file. > > Are you sure you need the path? There is no unique mapping from vnode > to path in FreeBSD (or in any Unix derivative for that matter); multiple > paths can lead to the same vnode. The kernel operates on vnodes, not > paths (except for namei, which translates paths to vnodes) and the path > to a vnode may change after a reference to the vnode is acquired (there > is no prohibition against deleting, renaming or moving an open file or > directory). Path components are cached in the namei cache, so it may > sometimes be possible to reconstruct the path by which a particular > vnode was most recently reached (vn_fullpath() does this), but the > information may also have been displaced from the cache since the last > lookup. > > If you just need a reference to the specified path or its parent > directory, a namei lookup of the path will do all the work for you. See > for instance kern_mkdir() in vfs_syscalls.c (which I assume you are > already looking at, since you are writing a replacement for the mkdir(2) > syscall) > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no >