linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Grant Likely" <grant.likely@secretlab.ca>
To: "Alan Stern" <stern@rowland.harvard.edu>
Cc: Peter Korsgaard <jacmet@sunsite.dk>,
	linux-usb-devel@lists.sourceforge.net,
	linuxppc-embedded@ozlabs.org
Subject: Re: [linux-usb-devel] [PATCH 6/6] [C67x00] Merge c67x00-hub.c into c67x00-hcd.c
Date: Wed, 13 Jun 2007 09:09:25 -0600	[thread overview]
Message-ID: <fa686aa40706130809q78a875f5u45e458eaa54eae2d@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0706131033480.3467-100000@iolanthe.rowland.org>

On 6/13/07, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 13 Jun 2007, Grant Likely wrote:
>
> > On 6/12/07, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> > > >>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
> > >
> > > Hi,
> > >
> > >  Grant> Rather than c67x00-hub.c being compiled seperately, the
> > >  Grant> original code had c67x00-hub.c *included* by c67x00-hcd.c.
> > >  Grant> This is a very bad idea.
>
> What's so bad about it?  It's an elegant solution to the problem of
> breaking a very long driver up into smaller, more digestible pieces
> without polluting the kernel's namespace with lots of extra global
> symbols.

Primarily because it breaks convention.  Convention is that you
#include .h files, and you compile and link .c files.  Convention is
important because it reflects the common patterns we use when reading
and writing (but mostly reading) code.

Yes there are exceptions, and yes it can be done, but there better be
a damn good reason for doing so.  In this particular case, I really
don't think it is warranted.  We're not talking about a great deal of
code, and we're *already* polluting the kernel namespace with c67x00_*
function names because the driver is already in multiple pieces.

This issue has also come up on the LKML also.  See this thread:

http://thread.gmane.org/gmane.linux.kernel/498633

> What's so ugly about breaking a driver up into pieces?  Leaving it in
> one giant piece would be much more ugly IMO.

Breaking into pieces: Good, and I fully agree.
Doing it in non-standard way: Not so good as it trades one kind of
ugliness for another.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

  reply	other threads:[~2007-06-13 15:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-12 23:02 [PATCH 0/6] Cleanups to c67x00 USB host controller driver Grant Likely
2007-06-12 23:02 ` [PATCH 1/6] [C67x00] Add test of active flag when checking TDs Grant Likely
2007-06-12 23:02   ` [PATCH 2/6] [C67x00] Fix calculation of frame bandwidth Grant Likely
2007-06-12 23:02     ` [PATCH 3/6] [C67x00] Remove unnecessary references to pt_regs Grant Likely
2007-06-12 23:02       ` [PATCH 4/6] [C67x00] Added error handling paths to lowlevel interface code Grant Likely
2007-06-12 23:02         ` [PATCH 5/6] [C67x00] Change 'struct c67x00_drv' to 'struct c67x00_device' Grant Likely
2007-06-12 23:02           ` [PATCH 6/6] [C67x00] Merge c67x00-hub.c into c67x00-hcd.c Grant Likely
2007-06-13  5:58             ` Peter Korsgaard
2007-06-13 12:54               ` Grant Likely
2007-06-13 13:59                 ` [linux-usb-devel] " phil culler
2007-06-13 14:33                   ` Grant Likely
2007-06-13 14:37                 ` Alan Stern
2007-06-13 15:09                   ` Grant Likely [this message]
2007-06-13 15:43                     ` Alan Stern
2007-06-13 16:19                       ` Grant Likely
2007-06-13 16:38                         ` Alan Stern
2007-07-30 16:51 ` I2C interrupts on 8541 Charles Krinke
2007-07-31 14:14   ` Kumar Gala

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=fa686aa40706130809q78a875f5u45e458eaa54eae2d@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=jacmet@sunsite.dk \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=stern@rowland.harvard.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).