Messages in this thread | ![/](/images/icornerl.gif) | | From | "Michael L. Welles" <> | Date | Mon, 16 Apr 2001 18:42:52 -0400 (EDT) | Subject | kernel space getcwd()? (using current() to find out cwd) |
| |
This is probably a stupid question, and probably directed to the wrong list. Apologies in advance, but I'm stumped
I've been working on a kernel module to report on "changed files". It works just fine -- I wrap the orignal system calls with my replacements which queue the filenames being modified, and when another proccess reads from the device or proc entry, they get a nice snapshot of what's going on in the system -- except that all the paths are relative to the calling process.
So, a little ignorance being a dangerous thing, I thought I'd be clever and manually reconstruct the full path by walking up current->fs->pwd->d_parent and padding d_name to the filename until it hits root.
Unfortunatly, this approach causes kernel panics. e.g., the attached code snippet will inevitably bring down the machine if I call it during in my replacement open, mkdir, rmdir, unlink routines -- and tehy all work fine without itq.
What am I not getting? I do see, before I go down, that there's a few occasions where current() is NULL...
Apologies in advance for a wordy, probably stupid question, but I'm stumped.
If this is not the right approach for what I'm trying to do (e.g. a kernel space getcwd()), can someone point me to something else I can try?
Thanks in advance,
Mike Welles
----------------------------------------
(this is the greatly reduced version which does nothing but try and reference current->fs->pwd)
void fill_full_path(char *name) { if (current==NULL) { #ifdef DEBUG printk("ERROR! current == NULL\n"); #endif return; }
if (current->fs==NULL) { #ifdef DEBUG printk("ERROR! current-> == NULL\n"); #endif return; }
if (current->fs->pwd==NULL) { #ifdef DEBUG printk("ERROR! current->fs->pwd == NULL\n"); #endif return; }
return; }
This is probably a stupid question: I've been working on a kernel module to report on "changed files".
It works just fine -- I wrap the orignal system calls with my replacements which queue the filenames being modified, and when another proccess reads from the device or proc entry, they get a nice snapshot of what's going on in the system -- except that all the paths are relative to the calling process.
So, a little ignorance being a dangerous thing, I thought I'd be clever and manually reconstruct the full path by walking up current->fs->pwd->d_parent and padding d_name to the filename until it hits root.
Unfortunatly, this approach causes kernel panics. e.g., the attached code snippet will inevitably bring down the machine if I call it during in my replacement open, mkdir, rmdir, unlink routines -- and tehy all work fine without itq.
What am I not getting? I do see, before I go down, that there's a few occasions where current() is NULL...
Apologies in advance for a wordy, probably stupid question, but I'm stumped.
If this is not the right approach for what I'm trying to do (e.g. a kernel space getcwd()), can someone point me to where I should look?
Thanks in advance,
Mike Welles
----------------------------------------
(this is the greatly reduced version which does nothing but try and reference current->fs->pwd)
void fill_full_path(char *name) { if (current==NULL) { #ifdef DEBUG printk("ERROR! current == NULL\n"); #endif return; }
if (current->fs==NULL) { #ifdef DEBUG printk("ERROR! current-> == NULL\n"); #endif return; }
if (current->fs->pwd==NULL) { #ifdef DEBUG printk("ERROR! current->fs->pwd == NULL\n"); #endif return; }
return; }
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |