Subject: Re: [PATCH 03/16] batman-adv: add bat_orig_print API function

From: Antonio Quartulli <[email-masked]>
Date: Wed, 23 Oct 2013 19:37:56 +0200

On Wed, Oct 23, 2013 at 10:27:13AM -0700, Joe Perches wrote:
> On Wed, 2013-10-23 at 19:18 +0200, Antonio Quartulli wrote:
> > On Wed, Oct 23, 2013 at 10:00:30AM -0700, Joe Perches wrote:
> > > On Wed, 2013-10-23 at 18:04 +0200, Antonio Quartulli wrote:
> > > > Each routing protocol has its own metric and private
> > > > variables, therefore it is useful to introduce a new API
> > > > for originator information printing.
> > > > 
> > > > This API needs to be implemented by each protocol in order
> > > > to provide its specific originator table output.
> > > []
> > > > +static void batadv_iv_ogm_orig_print(struct batadv_priv *bat_priv,
> > > > +				     struct seq_file *seq)
> > > []
> > > > +	seq_printf(seq, "  %-15s %s (%s/%i) %17s [%10s]: %20s ...\n",
> > > > +		   "Originator", "last-seen", "#", BATADV_TQ_MAX_VALUE,
> > > > +		   "Nexthop", "outgoingIF", "Potential nexthops");
> > > 
> > > This header printf really doesn't add much with the formatting sizes.
> > > It's pretty obscure why some of these are sized and others not sized.
> > > For instance: %-15s doesn't refer to a mac address size.
> > > Perhaps it'd be better to just emit the fixed string just using
> > > BATADV_TO_MAX_VALUE.  It'd also be easier to find via grep.
> > 
> > This string is printed out of a debugfs file and follows a format that we have
> > been using for long time (this patch is just moving this code from one point to
> > another).
> 
> I saw.
> 
> > I didn't get what you mean with BATADV_TO_MAX_VALUE (maybe you meant
> > BATADV_TQ_MAX_VALUE? but even in this case I don't get it).
> 
> Yeah, TQ not TO.  Both look similar with squiggles
> underneath them when using spell checking.
> 
> It's a #define, all the others are fixed strings.
> 
> Anyway, using
> 	seq_printf(seq, "  Originator      last-seen (#/%d)           Nexthop [outgoingIF]:   Potential nexthops ...\n",
> 		   BATADV_TQ_MAX_VALUE);
> is probably trivially smaller overall code size too.
> 
> Your code, you decide...

Now I fully understand your point.

Honestly I agree with you, but this string is there since a while and I'd
like to get a feedback from the other guys before changing it.

If for David it is not a problem I'd like keep it like that and I'll discuss and
possibly add this change (this is not the only header in the code printed this
way) later.

Thanks a lot for your feedback!

Cheers,

-- 
Antonio Quartulli