From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Sun, 30 Dec 2001 07:49:42 +0000 Subject: Re: Is there a bug in hotplug.functions w/ ${TYPE}.usermap? Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Since you sent that original reply privately, I couldn't see that you had _also_ sent a copy to the list. Please don't do that. ----- Original Message ----- From: "David Brownell" To: "Stamatis Mitrofanis" Sent: Saturday, December 29, 2001 11:34 PM Subject: Re: Is there a bug in hotplug.functions w/ ${TYPE}.usermap? > > Oops... I really hate ugly code though. > > You're basically complaining because it doesn't match your > own coding style. That has nothing to do with being ugly; it's > pure flaming. Which doesn't help your cause at all (hint). > > > > Well, not all drivers are drivers, if you ask me. The net agent, for > > example, doesn't "load" drivers at all. The interface with the kernel > > describes "events", not directly requests for drivers. > > Yes, hotplugging isn't only about loading drivers. Never has been. > If I've ever implied otherwise, it's because I've been spending so > much time talking with folk who don't realize that. > > Not that the "net" agent talks "driver", it talks "network interface" > (device). It's a level above device drivers. > > > > There's not much in this "common logic" anyway. The way the function is > > written makes it seem like there is. It's huge and full of unnecessary > > things > > Then we'll just disagree. I've used versions with and without code > sharing, and I know which style of agent is smaller. And I've worked > with systems designed the way you're advocating (no shared code). > > Those are horrible to use or maintain, because every subsystem > ends up doing the same things in different ways, and none will > quite the same (or right) thing. Users end up hating them because > nothing is predictable enough to understand, it's nothing more than > a collection of kluges. Maintainers hate them because updates > need to touch dozens of parts rather than a single one, and they > only way to add updates is piling kluge on top of kluge. And while > that may not matter in this case, that's the best way for security holes > grow: kluge on kluge, with nothing consistent enough for anyone > to know what's going to break when one gets fixed. > > > > So off goes the *_map_functions bloat of load_driver . It can simply use > > *modules . > > No it can't. "usbdevfs" is completely optional, and most systems > don't have either "usbmodules" or "pcimodules". The *_map functions > are the required parts, the rest is optional gravy (mostly there to deal > with the "coldplug" cases). > > > > instead of calling the script _after_ the module is loaded... > > > > _call_the_script_instead_of_loading_the_module_ , > > and if it doesnt exist, do load the kernel module. > > I've thought about that before, but it's got some problems too. > > For one, it'd break existing scripts, and (often worse) knowledge > that folk have already about using them. For another, there's no > compelling example motivating such a change -- no problem > that folk have hit (real-world) that doesn't have a good solution > within the existing framework. > > - Dave > > _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel