On 06/15/2011 08:12 PM, Steve French wrote: > > The idea of the 1st parameter to cerror was to allow turning off log > spam more easily if error turned out to be expected. Gave some > flexibility debugging too. Ok, but still it doesn't allow us to turn off logs in the runtime (have to be recompiled, right?). OTOH, wouldn't be easier to convert a cERROR to cFYI in case if we found if the error is expected or use cifswarn() instead? > On Jun 15, 2011 8:08 AM, "Suresh Jayaraman" <sjayaraman@xxxxxxx > <mailto:sjayaraman@xxxxxxx>> wrote: >> On 06/15/2011 06:28 PM, Jeff Layton wrote: >>> On Wed, 15 Jun 2011 15:10:45 +0530 >>> Suresh Jayaraman <sjayaraman@xxxxxxx <mailto:sjayaraman@xxxxxxx>> wrote: >>> >>>> On 06/14/2011 09:30 PM, Jeff Layton wrote: >>>>> On Tue, 14 Jun 2011 21:07:47 +0530 >>>>> Suresh Jayaraman <sjayaraman@xxxxxxx <mailto:sjayaraman@xxxxxxx>> > wrote: >>>>> >>>>>> ... for uniformity and cleaner debug logs. >>>>>> >>>>>> Signed-off-by: Suresh Jayaraman <sjayaraman@xxxxxxx > <mailto:sjayaraman@xxxxxxx>> >>>>>> --- >>>>>> fs/cifs/cache.c | 6 +++--- >>>>>> fs/cifs/fscache.c | 53 > +++++++++++++++++++++++++---------------------------- >>>>>> 2 files changed, 28 insertions(+), 31 deletions(-) >>>>>> >>>>>> diff --git a/fs/cifs/cache.c b/fs/cifs/cache.c >>>>>> index dd8584d..545509c 100644 >>>>>> --- a/fs/cifs/cache.c >>>>>> +++ b/fs/cifs/cache.c >>>>>> @@ -92,7 +92,7 @@ static uint16_t cifs_server_get_key(const void > *cookie_netfs_data, >>>>>> break; >>>>>> >>>>>> default: >>>>>> - cERROR(1, "CIFS: Unknown network family '%d'", sa->sa_family); >>>>>> + cERROR(1, "Unknown network family '%d'", sa->sa_family); >>>>> ^^^^^^^^^ >>>>> Maybe this would be a good time to add in a new >>>>> cFYI/cERROR "flag" for fscache and convert all of these >>>>> to use it? >>>> >>>> Sounds like a good idea to flag fsc debug messages separately but >>>> flagging errors separately would be useful? >>>> >>> -- Suresh Jayaraman -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
