All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gihan Munasinghe <GMunasinghe@flexiant.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [PATCH] syslog support to xentoollog
Date: Mon, 07 Jun 2010 12:36:02 +0100	[thread overview]
Message-ID: <4C0CD9A2.8010002@flexiant.com> (raw)
In-Reply-To: <19468.51942.998644.811395@mariner.uk.xensource.com>

Ian Jackson wrote:
> Gihan Munasinghe writes ("[PATCH] syslog support to xentoollog"):
>   
>> Going forward I would like to suggest that xentoollog.h file should only 
>> have generic functions, except for xtl_createlogger_* functions. Logger 
>> type specific function should not be included(e.g 
>> xtl_stdiostream_set_minlevel ) this will make sure outside code can 
>> switch from one logger to another (from stdiologger to syslogger vice 
>> versa) with out breaking the code.
>>     
>
> In general this is a good idea but it's not sensible to make it a hard
> and fast rule.  Eg, if you had a function xtl_syslog_change_facility()
> it wouldn't make any sense for it to be implemented by stdiostream.
>
>   
Should a call like xtl_syslog_change_facility() given out directly to 
the library users. this call can be wrapped with in a more generic call 
like
xtl_cahnge_log_place(struct xentool_logger , void *new_place);

In stdiostream implementation this can be caste to a stream and in 
syslogger implementation this can be cast as a  facility.
If some logger doesn't want to implement that we can have empty 
implementation

Well may be it should not be a hard and fast rule, but more of a best 
practice scenario then.


Thanks
Gihan

  reply	other threads:[~2010-06-07 11:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-02 21:39 syslog support to xentoollog Gihan Munasinghe
2010-06-03 10:21 ` Stefano Stabellini
2010-06-03 14:31   ` Gihan Munasinghe
2010-06-04 11:25     ` Ian Jackson
2010-06-05  0:51       ` [PATCH] " Gihan Munasinghe
2010-06-07  6:51         ` Keir Fraser
2010-06-07 10:37           ` Ian Jackson
2010-06-07 10:33         ` Ian Jackson
2010-06-07 11:36           ` Gihan Munasinghe [this message]
2010-06-07 11:51             ` Ian Jackson
2010-06-07 10:36         ` Ian Jackson
2010-06-07 11:37           ` Gihan Munasinghe
2010-06-07 11:51         ` Ian Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C0CD9A2.8010002@flexiant.com \
    --to=gmunasinghe@flexiant.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.