Erez Zilber wrote:
> On Mon, Dec 7, 2009 at 7:24 PM, Mike Christie <> wrote:
>> 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.
> Sure. The only thing that I don't know is how to get the
> sessionX/connectionY string in userspace. Where is it stored?

session->id is the X in sessionX and session->conn[0]->id is the Y in 


You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to