Re: Is there a bug in hotplug.functions w/ ${TYPE}.usermap?

[David Brownell <david-b@pacbell.net>]

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" <david-b@pacbell.net>
To: "Stamatis Mitrofanis" <ewstam@softhome.net>
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