On Fri, 24 Aug 2007 12:31:43 -0400 Scott Thompson wrote:
> On Fri, 24 Aug 2007 07:07:54 -0400 Jesper Juhl
> <[EMAIL PROTECTED]> wrote:
> >On 24/08/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> >> > I think this is also a matter of conding style.
> >Documentation/CodingStyle says:
> >> >
> >> > "The limit on the length of lines is 80 columns and this is a
> >hard limit."
> >>
> >> As has repeatedly been stated this is a bug in
> >Documentation/CodingStyle and bears no resemblence to reality.
> >>
>
> Quite the hornet's nest I've stirred up -- I'm not trying to rock
> the boat, just trying to row.
>
> Meanwhile, I ran a couple programs against the 2.6.22.1 source to
> get some statistics on the source in the linux kernel tree to
> understand what 'reality' is:
>
> Number of files -- 23742
> Number of lines > 80 columns: 247057
> Number of lines > 90 columns: 127016
> Number of lines > 100 columns: 21
>
> The *winner* at 482 columns is a commented out line in
>
> /linux-2.6.22.1/drivers/pci/hotplug/ibmphp_ebda.c 440 // debug
> ("rio_node_id: %x\nbbar: %x\nrio_type: %x\nowner_id:
> %x\nport0_node: %x\nport0_port: %x\nport1_node: %x\nport1_port:
> %x\nfirst_slot_num: %x\nstatus: %x\n", rio_detail_ptr->rio_node_id,
> rio_detail_ptr->bbar, rio_detail_ptr->rio_type, rio_detail_ptr-
> >owner_id, rio_detail_ptr->port0_node_connect, rio_detail_ptr-
> >port0_port_connect, rio_detail_ptr->port1_node_connect,
> rio_detail_ptr->port1_port_connect, rio_detail_ptr->first_slot_num,
> rio_detail_ptr->status);
>
> So I think updating the text in coding style one way or another is
> a good thing since there are ~248k exceptions to the style rule...
We could update CodingStyle, but it's still just a guideline,
not a strict requirement, so how would that fix anything?
> I can make the bins + scripts I used to gather this and output of
> this run available if anyone is interested.
>
> However, this isn't the whole story.. one of the side effects of
> the patch system through email clients are that the function name
> in the 'git diff' (or comparable) output can tack on 20-25 columns
> of header and further cause wordwrap strife and bring more patches
> into this problem. It *appears* that many maintainers are pretty
> good at recognizing this and purging portions of the function names
> when forwarding them around, but it's still a bigger and common
> 'problem' for the wordwrapping clients.
diff -p output is preferred for diffs (for review).
I'm not aware of people purging that info.
> Example:
> @@ -189,6 +189,9 @@ static __devinit int ixp4xx_pata_probe(struct
> platform_device *pdev)
>
> Common advice appears to be to get smtp working on gmail, and I
> thank the list for their suggestions. If I get one/two ways
> working that are compliant for patch submittal w/o wordwrap (et al)
> I'll start a 'howto' from my notes on yahoo and gmail/smtp setup
> and post that up on the interweb.
Thanks.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
