Erez Zilber 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).
> 2. For userspace code, we could do the same (i.e. have events and a
> log level per event).
> 3. Userspace logging uses the 'daemon' facility. This should
> definitely be the default, but we should allow the user to use another
> facility. The motivation for doing so is that if we want to send all
> iscsid logs to a separate file, we can set it to 'local2' for example
> (instead of 'daemon').
> 

Sorry for the late reply.

This sounds nice.

When you do this, could you also unify what gets printed to id what 
object is logging the message. Currently the kernel prints a session or 
conn sysfs/bus id (session1 or connection1:2), but userspace prints 
whatever it wants. Sometimes it just prints out a log with nothing so 
you have no idea where it came from, and sometimes it prints a id that 
looks like a sysfs one.

--

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.


Reply via email to