netdev - Re: [PATCH 080/493] fddi: remove use of __devexit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.02.1211212334080.25230@eddie.linux-mips.org>
Date:	Wed, 21 Nov 2012 23:49:50 +0000 (GMT)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Greg KH <gregkh@...uxfoundation.org>
cc:	Bill Pemberton <wfp5p@...ginia.edu>, netdev@...r.kernel.org
Subject: Re: [PATCH 080/493] fddi: remove use of __devexit_p

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html