Erez Zilber wrote: > On Mon, Dec 7, 2009 at 7:24 PM, Mike Christie <micha...@cs.wisc.edu> 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 connectionY. -- 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.
