| To: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 1/4] xfs: remove newlines from 3 xfs_alert_tag error strings |
| From: | Mark Tinguely <tinguely@xxxxxxx> |
| Date: | Fri, 11 Oct 2013 16:59:06 -0500 |
| Cc: | Eric Sandeen <sandeen@xxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx> |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <52584D04.3020907@xxxxxxxxxxx> |
| References: | <52584C8A.1060808@xxxxxxxxxx> <52584D04.3020907@xxxxxxxxxxx> |
| User-agent: | Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0 |
On 10/11/13 14:09, Eric Sandeen wrote: xfs_alert_tag passes the format string to __xfs_printk, which adds its own "\n". Having it in the original string leads to unintentional blank lines from these messages. Most format strings have no newline, but these 3 do, leading to i.e.: [ 7347.119911] XFS (sdb2): Access to block zero in inode 132 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a05 [ 7347.119911] [ 7347.119919] XFS (sdb2): Access to block zero in inode 132 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a05 [ 7347.119919] Signed-off-by: Eric Sandeen<sandeen@xxxxxxxxxx> Reviewed-by: Carlos Maiolino<cmaiolino@xxxxxxxxxx> --- Is this true of xfs_alert() too? ie the newline in xfs_alert in xfs_dir2_leafn_rebalance(). The newline in xfs_alert() in xlog_unpack_data_crc() looks intentional. --Mark. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 2/4] xfs: reject completely bogus remount options, Mark Tinguely |
|---|---|
| Next by Date: | Re: [PATCH 2/4] xfs: reject completely bogus remount options, Eric Sandeen |
| Previous by Thread: | [PATCH 1/4] xfs: remove newlines from 3 xfs_alert_tag error strings, Eric Sandeen |
| Next by Thread: | Re: [PATCH 1/4] xfs: remove newlines from 3 xfs_alert_tag error strings, Eric Sandeen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |