> Modern udev shouldn't be too much of a problem. However, programs with > suboptimal implementation regarding the handling of many devices may > slow down the system even worse if they see more events.
If configuration events like the ones we're discussion happen often enough to trigger this problem, I'd say the sub-optimal application is the one that's clearly in need of remedy, not the system itself. > > In the case of FCP disks, I know *I* care, and so I > > could decide what to do based on what happened. > Hm, maybe I should reconsider... change events may not be that bad. I think it would be a nice step toward the ability for the system to react to new devices in a automated way. > Well, if your configuration change makes your system unusable, it is > serious... > Most of the problem comes from the actions triggered by the > events. Good luck trying to get the consumers fix their stuff :() Your gun, your foot. 8-) > > I guess it comes down to how frequently one reconfigures devices. > Unexpected failures (which would be easily recoverable) may trigger an > event storm as well... I'm not sure there's much one can do about unanticipated failures -- those are going to be messy regardless. In a large configuration, that's going to look like a large-scale reconfig, in which we have to just power through the events and deal with it as queued. If the user configs a heavyweight reaction, that's going to be what will be, but at least he'll be *able* to configure the response. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
