On 10/11/2011 10:59 AM, rahul gupta wrote:
> Hi Mike/all,
>
> I am working on a part of user space 1 of TODO list, which precisely says-
>
No comments still. I guess logging is not fun :)
> the functions that were run (FUNCTION)
> the iSCSI packets that were sent/receieved (PDUS)
> print out extended iscsi login error information (LOGIN_ERRS)
>
> i) I have written log_debug to retrieve all functions names and print
> PDUS sent/recieved.
>
> but in case of FUNCTION for retrieving description I got two ways-
> (Please suggest which one is better approach)
>
> (all pls note that description always has to be in format just above
> function definition starts-
> /**
> * function name - function description
> )
>
> 1st approach-
> For getting description I will call a function,
> func_descrip(descrip, __FILE__ , __FUNCTION__, __LINE__);
> by this function I will fopen the file and then search for the
> desired function name whos one line back i will find /*,
> so that I will be sure this is the description of the desired function :) .
>
> 2nd approach is-
> I can create a global structure which will carry the function and
> its description, I mean something like:-
> struct func_name_descip{
> char func_name[20];
> char func_descrip[256];
> };
> and while executing discovery a function which will parse all .c files
> under "usr" directory and fill up this structure,
> while calling log_debug for FUNCTION, I will retrieve all values from
> the global object of this structure.
>
> disadvantage of 1st approach is- "its very time consuming task for
> iscsiadm"
> every time log_debug() is encountered then whole file is parsed for
> retrieving description which has been already parsed for other functions.
>
> Whereas disadv of 2nd one is - creating a global variable,
> also triggering it during discovery might slow up discovery too (but we can
> trigger it only when user specifies -d FUNCTION).
>
> I think second one is better. Please let me know anyone has a better
> idea, also share your views on these two.
I also do not like #1 so much.
How about just having us developers call some function we want logged?
I do not think this should be so bad and it is simple.
>
> ii) Regarding LOGIN_ERRS,
> after reading __check_iscsi_status_class(), I thought maybe it should
> come in debug with iscsid, I mean
> iscsid -f -d LOGIN_ERR
> and NOT iscsiadm -m node -T iqn.iet.target -p 102.2.2.2 -d LOGIN_ERR
> > In TODO, do you also mean't to say same as above I have written.
> well I can try to do it for any/both :) , let me know which one is
> desired/better.
Ah yeah, you are right. I was actually thinking both. iscsid might pass
back a more informative return value to iscsidm which would then print
it out to the user. Today, we just have login failed and login failed
due to CHAP error.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
