* Greg KH <greg@xxxxxxxxx>: > On Tue, Mar 24, 2009 at 06:40:56PM +0900, Taku Izumi wrote: > > > > > The reason I'm asking is because, if you're looking to get a > > > uevent emitted when the attention button is pressed or the MRL is > > > opened, well... why do you need it? The operator knows he pressed > > > the button or opened the latch. > > > > > > So I'm confused as to why software would need to know about these > > > physical events. > > > > > > > I think the sysfs operation for hotplug is not very nice, so I want to make > > the hotplug management utility. The utility that I have in mind has abilities > > - to display slots' status (power, latch, ...) > > - to show and record hotplug event log This sounds useful. > > - to perform hotplug operations > > - to show hotplug procedure automatically when the attention button is pressed. > > and so on. I think the event notification is variously useful... > > Is it unnecessary? > > Possibly, yes. You can do all of the above without the uevents being > sent from the kernel today, right? You can't log the number of times the attention button was pushed or the MRL was opened, afaik. > And, if the uevents are sent, udev will eat them up, how will your > application get access to them? Have you created new udev rules and/or > HAL code to emit those events to dbus properly? Example udev rules might be useful, just to prove that it works, but I don't think it should be required for kernel code. > Don't just add events from the kernel unless you have some code that > uses them :) This is a good rule of thumb. I'm not entirely opposed to Taku-san's patch set. For example, I could see logging hotplug events as a pretty useful feature for sysadmins who want an audit log of what a junior admin might have done in the data center. But I do agree that it would be nice to see some concrete examples of the actual use cases. Thanks. /ac -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
