netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Bill Pemberton <wfp5p@virginia.edu>, netdev@vger.kernel.org
Subject: Re: [PATCH 080/493] fddi: remove use of __devexit_p
Date: Wed, 21 Nov 2012 16:23:37 -0800	[thread overview]
Message-ID: <20121122002337.GA16151@kroah.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1211212334080.25230@eddie.linux-mips.org>

On Wed, Nov 21, 2012 at 11:49:50PM +0000, Maciej W. Rozycki wrote:
> Greg,
> 
> > >  I have unconfused myself now, so please replace the above with the 
> > > following question: what about configurations (e.g. buses) that not 
> > > support hotplug at all?  For example apart from PCI the defxx driver 
> > > concerned here supports the TURBOchannel bus that by design does not have 
> > > the concept of live option card removal (no such circuitry).  So should 
> > > now the precious memory be wasted on systems that will never ever handle 
> > > hotplug?
> > 
> > CONFIG_HOTPLUG is always enabled now, so that's not an option anymore.
> > And again, a user can "hot unbind" a driver from a device from
> > userspace, no matter if the bus physically supports it or not.
> 
>  Hmm, what purpose does this serve for devices that cannot be physically 
> removed?  If there is none, shouldn't that policy be set by individual 
> drivers or platform even?  Even if HOTPLUG as a whole is unconditional (I 
> suppose the amount of space core support itself takes is much less to what 
> driver code can).
> 
>  TURBOchannel, although valid, is an old exotic case that might not be 
> worth arguing for, except for purity maybe.  But there are surely many 
> contemporary systems out there that are known they are never going to 
> support hot device replacement.  Consider most of the embedded systems for 
> example, where devices may even physically be cast into a single SOC (with 
> no prospect of chipping off any pieces ever ;) ), that certainly could not 
> care less of device replacement, but they do care a lot about memory 
> consumption.

Even those don't care about less than 5k of memory, do they?

>  Was this implication considered, discussed and diregarded as not 
> important enough compared to benefits from hardcoding HOTPLUG support?  

Yes, I don't know of any modern system that does not enable
CONFIG_HOTPLUG, do you?

> I'm seriously asking for a pointer, not trying to cause any stir-up -- 
> regrettably I fail to follow most discussions these days, but I would like 
> to know what the background behind this decision was.  Thanks a lot!

See Russell's response in this thread for details if you are curious.

thanks,

greg k-h

  reply	other threads:[~2012-11-22 19:23 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1353349642-3677-1-git-send-email-wfp5p@virginia.edu>
2012-11-19 18:19 ` [PATCH 010/493] isdn: remove CONFIG_HOTPLUG ifdefs Bill Pemberton
2012-11-19 18:19 ` [PATCH 017/493] wireless: " Bill Pemberton
2012-11-19 18:19 ` [PATCH 018/493] net: " Bill Pemberton
2012-11-19 18:19 ` [PATCH 026/493] atm: remove use of __devexit_p in fore200e.c Bill Pemberton
2012-11-19 18:19 ` [PATCH 029/493] ethernet: remove use of __devexit_p in hydra.c Bill Pemberton
2012-11-19 18:19 ` [PATCH 039/493] atm: remove use of __devexit_p Bill Pemberton
2012-11-19 18:20 ` [PATCH 070/493] isdn: " Bill Pemberton
2012-11-19 18:20 ` [PATCH 078/493] arcnet: " Bill Pemberton
2012-11-19 18:20 ` [PATCH 079/493] can: " Bill Pemberton
2012-11-19 18:45   ` Marc Kleine-Budde
2012-11-19 18:20 ` [PATCH 080/493] fddi: " Bill Pemberton
2012-11-19 18:49   ` Maciej W. Rozycki
2012-11-19 18:57     ` Ben Hutchings
2012-11-19 19:08     ` David Miller
2012-11-19 19:16     ` Maciej W. Rozycki
2012-11-19 19:29       ` Greg KH
2012-11-19 21:22         ` Jan Engelhardt
2012-11-19 21:30           ` Bill Pemberton
2012-11-21 23:49         ` Maciej W. Rozycki
2012-11-22  0:23           ` Greg KH [this message]
2012-11-26  4:35             ` Maciej W. Rozycki
2012-11-26  9:33               ` David Laight
2012-11-19 18:20 ` [PATCH 081/493] hippi: " Bill Pemberton
2012-11-19 18:20 ` [PATCH 082/493] ieee802154: " Bill Pemberton
2012-11-19 18:20 ` [PATCH 083/493] irda: " Bill Pemberton
2012-11-19 18:20 ` [PATCH 084/493] phy: " Bill Pemberton
2012-11-19 18:20 ` [PATCH 086/493] net: " Bill Pemberton
2012-11-26 17:35   ` [Pv-drivers] " Dmitry Torokhov
     [not found] ` <1353349642-3677-1-git-send-email-wfp5p-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org>
2012-11-19 18:20   ` [PATCH 085/493] net/wireless: " Bill Pemberton
2012-11-19 20:56     ` Arend van Spriel
2012-11-22  6:04     ` Hin-Tak Leung
2012-11-19 18:21   ` [PATCH 126/493] rfkill: " Bill Pemberton
2012-11-19 18:21 ` [PATCH 136/493] ethernet: " Bill Pemberton
2012-11-20  9:31   ` Nicolas Ferre
2012-11-19 18:22 ` [PATCH 189/493] ssb: remove use of __devinit Bill Pemberton
2012-11-19 18:22 ` [PATCH 196/493] net/wireless: " Bill Pemberton
2012-11-19 20:03   ` Larry Finger
     [not found]   ` <1353349642-3677-196-git-send-email-wfp5p-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org>
2012-11-19 20:57     ` Arend van Spriel
2012-11-22  6:13     ` Hin-Tak Leung
2012-11-19 18:22 ` [PATCH 198/493] ethernet: " Bill Pemberton
2012-11-21 11:55   ` Russell King - ARM Linux
2012-11-19 18:22 ` [PATCH 200/493] irda: " Bill Pemberton
2012-11-19 19:06   ` David Miller
2012-11-19 19:21     ` Greg KH
2012-11-19 19:24       ` David Miller
2012-11-19 19:30         ` Greg KH
2012-11-19 20:25       ` Stephen Hemminger
2012-11-19 18:22 ` [PATCH 201/493] phy: " Bill Pemberton
2012-11-19 18:22 ` [PATCH 202/493] can: " Bill Pemberton
2012-11-19 18:48   ` Marc Kleine-Budde
2012-11-19 18:22 ` [PATCH 203/493] net: " Bill Pemberton
2012-11-26 17:38   ` [Pv-drivers] " Dmitry Torokhov
2012-11-19 18:22 ` [PATCH 204/493] atm: " Bill Pemberton
2012-11-19 18:23 ` [PATCH 232/493] isdn: " Bill Pemberton
2012-11-19 18:23 ` [PATCH 249/493] drivers: connector: " Bill Pemberton
2012-11-19 18:23 ` [PATCH 264/493] rfkill: " Bill Pemberton
2012-11-19 18:24 ` [PATCH 300/493] atm: remove use of __devinitdata Bill Pemberton
2012-11-19 18:24 ` [PATCH 311/493] isdn: " Bill Pemberton
2012-11-19 18:24 ` [PATCH 331/493] ethernet: " Bill Pemberton
2012-11-21 12:08   ` Russell King - ARM Linux
2012-11-19 18:24 ` [PATCH 333/493] net: " Bill Pemberton
2012-11-19 18:50   ` Marc Kleine-Budde
2012-11-19 20:02   ` Larry Finger
2012-11-19 18:25 ` [PATCH 351/493] atm: remove use of __devinitconst Bill Pemberton
2012-11-19 18:25 ` [PATCH 378/493] ethernet: " Bill Pemberton
2012-11-19 18:25 ` [PATCH 379/493] net: " Bill Pemberton
2012-11-19 18:51   ` Marc Kleine-Budde
2012-11-19 18:25 ` [PATCH 389/493] atm: remove use of __devexit Bill Pemberton
2012-11-19 18:25 ` [PATCH 410/493] isdn: " Bill Pemberton
2012-11-19 18:26 ` [PATCH 438/493] drivers: connector: " Bill Pemberton
2012-11-19 18:26 ` [PATCH 470/493] ethernet: " Bill Pemberton
2012-11-19 18:27 ` [PATCH 471/493] net: " Bill Pemberton
2012-11-19 18:56   ` Marc Kleine-Budde
2012-11-19 20:01   ` Larry Finger
2012-11-22  6:11   ` Hin-Tak Leung
2012-11-26 17:39   ` [Pv-drivers] " Dmitry Torokhov
2012-11-19 18:27 ` [PATCH 490/493] rfkill: " Bill Pemberton

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=20121122002337.GA16151@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=macro@linux-mips.org \
    --cc=netdev@vger.kernel.org \
    --cc=wfp5p@virginia.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).