Hi! One thing to decide would be whether you want to have hierarchical levels for debugging per subsystem (you call them "events" I think), or whether to have a bitmask-like value to enable or disable specific classes of messages (like openLDAP does it).
Personally I think that short debug output is perferrable to long output. With commercial software I have hjad several cases where support really wanted me to capture more than a GB of logs, where the logs contained really every stupid thing the program did. In the end they said they could not find the problem, because they did not log that specific case... 8-( Regards, Ulrich On 16 Dec 2009 at 17:31, Erez Zilber wrote: > On Wed, Dec 2, 2009 at 10:55 AM, Erez Zilber <erezzi.l...@gmail.com> wrote: > > I'd like to make some changes in the logging in open-iscsi. The > > current status is as follows: > > > > kernel modules: > > > > * We use iscsi_cls_session_printk & iscsi_cls_conn_printk in > > scsi_transport_iscsi.c. They are sometimes wrapped by macros (e.g. > > ISCSI_DBG_TRANS_SESSION). These macros use KERN_INFO and are > > controlled by module parameters. > > > > * We use iscsi_session_printk & iscsi_conn_printk for the rest of the > > kernel code.These macros wrap iscsi_cls_session_printk & > > iscsi_cls_conn_printk accordingly. They are sometimes wrapped by > > macros (e.g. ISCSI_SW_TCP_DBG). These macros use KERN_INFO and are > > controlled by module parameters. > > > > * We sometimes use printk calls. > > > > userspace: > > > > We use log_warning, log_error & log_debug. They depend on the logging > > level that we use (0-8). if (log_level > level), the log is sent to > > syslog with the appropriate log level (LOG_WARNING/LOG_ERR/LOG_DEBUG). > > > > My motivation: with the current logging mechanism, if an error occurs, > > I'm unable to tell exactly what happened. The default logging level is > > too low. Increasing it affects performance. Another problem is that > > open-iscsi has too many logging mechanisms. > > > > I suggest that: > > 1. For kernel modules, we will have 'events' (or any better name that > > you suggest) like 'session', 'conn', 'eh', 'cmd' etc. For each event, > > we will have a logging level. For example, the user may want to set > > the 'conn' event to 'DEBUG'. It means that we will print all conn > > related logs that are DEBUG and above (e.g. WARNING, ERROR). > > I suggest that each kernel module will have its own events. Each event > will be represented by a module parameter (with some default value). > > > 2. For userspace code, we could do the same (i.e. have events and a > > log level per event). > > Regarding the 'events' in userspace - we will have events A, B & C for > iscsid and events D, E & F for iscsiadm. For each event, we will > probably have a default logging level. The user may want to run with > another logging level for each event. For iscsid, I suggest that we > add this to iscsid.conf. For iscsiadm, the user will be able to do > something like: > > iscsiadm -d some_level - this will set all events to 'some_level' > iscsiadm -dE level_for_E -dF level_for_F - this will set the event 'E' > to 'level_for_E' and the event 'F' to 'level_for_F'. The event 'D' > will use the default logging level. > > Comments? > > Thanks, > Erez > > -- > > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To post to this group, send email to open-is...@googlegroups.com. > To unsubscribe from this group, send email to > open-iscsi+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/open-iscsi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
