All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bryan O'Sullivan" <bos@pathscale.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, openib-general@openib.org
Subject: Re: [PATCH 11 of 20] ipath - core driver, part 4 of 4
Date: Fri, 30 Dec 2005 15:17:55 -0800	[thread overview]
Message-ID: <1135984675.13318.58.camel@serpentine.pathscale.com> (raw)
In-Reply-To: <20051230081218.GB7438@kroah.com>

On Fri, 2005-12-30 at 00:12 -0800, Greg KH wrote:

> This has grown
> into a huge file, can't you split it up into smaller pieces?

Absolutely.

> Why even save off the return value if you don't do anything with it?

I think that's just a throwback to an earlier rev of the driver.

> And please don't put assignments in the middle of if statements, that's
> just messy and harder to read (the fact that gcc made you put an extra
> () should be a hint that you were doing something wrong...)

OK.

> And does your driver work with udev?  I didn't see where you were
> exporting the major:minor number of your devices to sysfs, but I might
> have missed it.

It was written in a pre-udev world, so it still uses a fixed major and
minor number.  How important is this to you?  Is it "nice to have", or
"blocker"? :-)

> Are you sure that's a good idea?  Please do the proper thing and tear
> down your infrastructure if something fails, that's the correct thing to
> do.  That way you can actually recover if something that you call in
> this function fails (like driver_create_file(), or
> pci_register_driver().) Functions don't return error values just so you
> can ignore them :)

This will take a bit of cleaning up, but it's a reasonable request.

> > +/*
> > + * note: if for some reason the unload fails after this routine, and leaves
> > + * the driver enterable by user code, we'll almost certainly crash and burn...
> > + */
> 
> See, you admit that what you are doing isn't the wisest thing, which
> should tell you something...

Indeed.

> This is the call that should have cleaned up all of the memory and other
> stuff that you do above.  If not, then your driver will not work in any
> hotplug pci systems, which would not be a good thing.  Please do like
> Roland says and put your resources and stuff in the device specific
> structures, like the rest of the kernel drivers do.

I'm working on the appropriate hearts and minds as we speak :-)

> Why not just export ipath_ht_get_boardname instead?

Because that's too specific to HT for my personal liking.

> > +module_init(infinipath_init);
> > +module_exit(infinipath_cleanup);
> > +
> > +EXPORT_SYMBOL(infinipath_debug);
> > +EXPORT_SYMBOL(ipath_get_boardname);
> 
> EXPORT_SYMBOL_GPL() ?

I don't see a problem with that.

> And put them next to the functions themselves, it's easier to notice
> that way.

OK.

Thanks again for the review,

	<b


  reply	other threads:[~2005-12-30 23:17 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-29  0:31 [PATCH 0 of 20] [RFC] ipath - PathScale InfiniPath driver Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 1 of 20] Introduce __memcpy_toio32 Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 2 of 20] memcpy32 for x86_64 Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 3 of 20] Add memcpy_toio32 to each arch Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 4 of 20] Define BITS_PER_BYTE Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 5 of 20] ipath - driver core header files Bryan O'Sullivan
2005-12-29  8:18   ` Pekka Enberg
2005-12-29 14:15     ` Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 6 of 20] ipath - driver debugging headers Bryan O'Sullivan
2005-12-29  8:22   ` Pekka Enberg
2005-12-29  0:31 ` [PATCH 7 of 20] ipath - MMIO copy routines Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 8 of 20] ipath - core driver, part 1 of 4 Bryan O'Sullivan
2005-12-30  8:39   ` Greg KH
2005-12-30 23:47     ` Bryan O'Sullivan
2005-12-31  0:12       ` Greg KH
2005-12-29  0:31 ` [PATCH 9 of 20] ipath - core driver, part 2 " Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 10 of 20] ipath - core driver, part 3 " Bryan O'Sullivan
2005-12-30 18:46   ` Linus Torvalds
2005-12-30 23:50     ` Bryan O'Sullivan
2005-12-31  8:36       ` Arjan van de Ven
2005-12-29  0:31 ` [PATCH 11 of 20] ipath - core driver, part 4 " Bryan O'Sullivan
2005-12-29  2:19   ` [openib-general] " Roland Dreier
2005-12-29 14:21     ` Bryan O'Sullivan
2005-12-30  8:12   ` Greg KH
2005-12-30 23:17     ` Bryan O'Sullivan [this message]
2005-12-31  0:08       ` Greg KH
2005-12-29  0:31 ` [PATCH 12 of 20] ipath - misc driver support code Bryan O'Sullivan
2005-12-30  8:25   ` Greg KH
2005-12-30 23:10     ` Bryan O'Sullivan
2005-12-31  0:13       ` Greg KH
2005-12-30 18:15   ` Arjan van de Ven
2005-12-29  0:31 ` [PATCH 13 of 20] ipath - routines used by upper layer driver code Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 14 of 20] ipath - infiniband verbs header Bryan O'Sullivan
2005-12-29  8:21   ` Pekka Enberg
2005-12-29 14:22     ` Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 15 of 20] ipath - infiniband verbs support, part 1 of 3 Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 16 of 20] path - infiniband verbs support, part 2 " Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 17 of 20] ipath - infiniband verbs support, part 3 " Bryan O'Sullivan
2005-12-29 19:24   ` Pekka Enberg
2005-12-30  3:19     ` Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 18 of 20] ipath - infiniband management datagram support Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 19 of 20] ipath - kbuild infrastructure Bryan O'Sullivan
2005-12-29  0:31 ` [PATCH 20 of 20] ipath - integrate driver into infiniband " Bryan O'Sullivan
2005-12-29 19:01 ` [PATCH 0 of 20] [RFC] ipath - PathScale InfiniPath driver Horst von Brand
2005-12-29 19:26   ` Lee Revell
2005-12-31  5:36     ` Jan Engelhardt
2006-01-02 16:05     ` Horst von Brand
2006-01-02 16:22       ` Christoph Hellwig
2005-12-30  3:17   ` Bryan O'Sullivan
2005-12-30  8:00 ` Greg KH
2005-12-30 23:11   ` Bryan O'Sullivan
2005-12-31  0:10     ` Greg KH
2005-12-31  1:40       ` Bryan O'Sullivan
2006-01-02 20:35         ` Eric W. Biederman
2006-01-02 22:22           ` Bryan O'Sullivan
2006-01-04 21:26           ` Roland Dreier
2006-01-05 15:28             ` Bryan O'Sullivan
2006-01-03 17:27         ` Greg KH
2006-01-03 20:54           ` Bryan O'Sullivan
2006-01-03 20:57             ` Arjan van de Ven
2006-01-03 21:24               ` Bryan O'Sullivan
2006-01-03 21:26                 ` Arjan van de Ven
2006-01-04  3:33                   ` Bryan O'Sullivan
2006-01-04 21:28             ` [openib-general] " Roland Dreier
2006-01-05 15:31               ` Bryan O'Sullivan

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=1135984675.13318.58.camel@serpentine.pathscale.com \
    --to=bos@pathscale.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openib-general@openib.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.