> > That seems kind of counter-intuitive. A device clearly just changed > > state in an important way -- shouldn't that be something udev should > > care about, or at least be notified of? Udev can always choose to ignore > > the events. > Well, uevents are mainly created when devices are added/removed to/from > the system. Setting a device online/offline only changes some > attributes for an existing device.
True. I think it could be argued that that change (a device going unavailable or coming back) might need some reaction from elsewhere in the system, so it would be good to let udev know, and let udev decide if it cares or not. In the case of FCP disks, I know *I* care, and so I could decide what to do based on what happened. > > > You might observe the fact that in old SLES9 kernels, the SCSI host > > > adapter for zfcp was registered when setting the CCW device online and > > > unregistered when setting the CCW device offline. This was changed, so > > > that setting the CCW device offline, does not remove the SCSI host > > > adapter. The change was necessary, because going through the sequence > > > "offline adapter" -> "online adapter" has to present the same SCSI > > > devices to not confuse the multipathing layer. > > > > Makes sense. > > OK, so no notification is generated in this case... Yes, in the multipathing case. If there was only one path, I'd still want the adapter to go away because it really IS gone. > > > As an alternative, i would suggest putting the FCP adapters, ports and > > > LUNs in some simple scripts, that do not rely on hotplug events. > > Ugh. Isn't that the point of hotplug support -- so that we don't have to > > do stuff like that? > ...so a better solution may be to have zfcp generate a uevent here? > (I'm not too happy with adding uevents whether they are needed or not. > Too many uevents create a high system load from some tools.) I can think of two major cases where you'd get a burst of these: during startup, and during a reconfiguration. In both cases, I think you'd expect them because the I/O system is doing what it's supposed to do, and hopefully it shouldn't happen too often. I guess I'd consider this kind of configuration change to be an exception. If it does happen (or there are overzealous event consumers polling for events) very often, I think the problem is likely to be a) more serious and/or b) fixable elsewhere. I guess it comes down to how frequently one reconfigures devices. ---------------------------------------------------------------------- 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
