LinuxQuestions.org - Return code while writing to procfs

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - Return code while writing to procfs (https://www.linuxquestions.org/questions/programming-9/return-code-while-writing-to-procfs-589081/)

Return code while writing to procfs

Hi,
I am a newbie in Module programming. I wanted to know
whether i can return a specific exit code other than
predefined ones while writing to a proc entry.
For example if there is an error while writing to a proc entry
can i have an exit code like e.g. 1234.
This will help me in more specifically pointing out the reason
for the error.
For example i do
$bash] echo "This echo whill fail" > /proc/dummy/waste

Suppose the write failed because of Error "Some weired Error",
which i have defined to be error number 1234 in my error file,
i should get 1234 in $? on the shell prompt.
But all the friends i asked for help told me that they dont
know of any such way, and they can return only whether
command suceeded or command failed. I cannot pin point reason
behind the error :(
But i think there has to be atleast some work around to
get specific exit code, so that i can parse an error file for that
exit code, and echo the specific reason.
Thanks in advance.....

Hya,

I somewhat think you have to use C to satisfy your wish.

Even in that case, I do not think you can have 1234 as an exit code. I may be wrong but exit code needs to be 8 bit.

Happy Penguins!

Hi,
By 1234 i meant any code other than -1, 0 and 1.
That is when i echo something to proc, i should be
able to return a specific code which represents a specific
error; rather than just telling that there was an error
or not.

Quote:

Originally Posted by e-razor (Post 2912578)

I think what kaz is saying is that you can’t dictate the return code of echo (a userspace program) from the kernel. What you can do is read the appropriate errno value and interpret it as you like in a C program. In fact, on my system, echo will do just that. Instead of returning the error number, however, it will write some diagnostic output and have an exit code of 1. So basically, you can chose any of the “specific error” codes available as system error numbers. That’s as close as you’re going to get.

To show this, consider the module made of a file waste.c:

Code:

#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/proc_fs.h>

#include <linux/string.h>



MODULE_LICENSE("GPL");

MODULE_AUTHOR("osor");



static struct proc_dir_entry *dummy, *waste;

char dir_name [] = "dummy";

char entry_name [] = "waste";



static int write_waste(struct file *file,

                      const char *buffer,

                      unsigned long count, 

                      void *data)

{

        if(!strncmp("This should say \"Bad address\"\n", buffer, count))

                return -EFAULT;

        if(!strncmp("This should say \"Resource temporarily unavailable\"\n",

                    buffer, count))

                return -EAGAIN;

        return -EINVAL; /* Default is "Invalid argument" */

}



int init_module()

{

        dummy = proc_mkdir(dir_name, NULL);

        if(dummy == NULL) {

                printk(KERN_ALERT "Error: Could not initialize /proc/%s\n",

                      dir_name);

                return -ENOMEM;

        }

        waste = create_proc_entry(entry_name, 0222, dummy);

        waste->write_proc = write_waste;

        if (waste == NULL) {

                remove_proc_entry(entry_name, dummy);

                remove_proc_entry(dir_name, NULL);

                printk(KERN_ALERT "Error: Could not initialize /proc/%s/%s\n",

                      dir_name, entry_name);

                return -ENOMEM;

        }



        return 0;

}



void cleanup_module()

{

        remove_proc_entry(entry_name, dummy);

        remove_proc_entry(dir_name, NULL);

}

Now watch what happens when we test it:

Code:

$ sudo modprobe waste

$ ls -l /proc/dummy/waste 

--w--w--w- 1 root root 0 2007-10-04 23:24 /proc/dummy/waste

$ echo 'This should say "Bad address"' > /proc/dummy/waste

bash: echo: write error: Bad address

$ echo $?

1

$ echo 'This should say "Resource temporarily unavailable"' > /proc/dummy/waste

bash: echo: write error: Resource temporarily unavailable

$ echo $?

1

$ echo foo > /proc/dummy/waste

bash: echo: write error: Invalid argument

$ echo $?

1

So although in each case, echo tells you that en error occurred (i.e., the exit code is 1), in each case, it also lets you know something specific.

Why not just proc_create_entry for "code" and/or "message" (below dummy) as well to expose more info if necessary ???.

Hi syg00,
The problem with having another proc entry e.g. /proc/dummy/code for error code comes,when i have almost simultaneous writes on the proc/dummy/waste.
The first command fails, and the /proc/dummy/code has the error code e.g. 12,
but before i read /proc/dummy/code another write to dummy/waste is successfull, and i wont see specific reason for the error as /proc/dummy/code shows 0.
So i think osor's way seems to be the best solution , but my bash does
not give those messages when i tried running osor's code. my bash version is 3.00.15. Do i need to enable something in bash for that?

Quote:

Originally Posted by e-razor (Post 2913996)

my bash does
not give those messages when i tried running osor's code. my bash version is 3.00.15. Do i need to enable something in bash for that?

For me, it works on bash-3.2 and 3.1, but not on 3.0. Regardless of your shell, you could always use the non-builtin version of echo (usually it’s just “/bin/echo”). For me, it gives similar output with coreutils-6.9:

Code:

$ /bin/echo "foo" > /proc/dummy/waste

/bin/echo: write error: Invalid argument

$ echo $?

1

In any case, you should not depend on the specific implementation of a userspace program when looking for errors. The best thing to do is to establish (i.e., document in an API) what each errno means for a write to your particular proc_entry. Let specialized programs look for such errno values upon the write() system call and handle them accordingly.