Re: [PATCH 080/493] fddi: remove use of __devexit_p

["Maciej W. Rozycki" <macro@linux-mips.org>]

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.

 Was this implication considered, discussed and diregarded as not 
important enough compared to benefits from hardcoding HOTPLUG support?  
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!

  Maciej