Kay, The approach shown in the patch may have indeed a performance impact which we understand must be avoided. But I take it you are not generally opposed to providing such an interface, assuming it is implemented in a way that does not interfere with the existing mode of operation? Let me explain a little bit why we think this interface would be helpful... We want to write unit tests for applications that interact with udev (get notified when devices pop up/disappear), and for this we need an abstraction layer that we can mock. libudev has a nice clean interface that fits this purpose very well actually, but we cannot obtain a list of attributes through libudev (why we sometimes need that, see below). This means that we are building a secondary abstraction to just obtain the list of attributes, and strictly funnel everything else through libudev. We then provide "mock" and "real" implementations of both, and make sure to "tie" the two different implementations properly (which deeply interact for the "mock" case under the hood). As you can imagine, this is "a bit" messy. The test cases to be injected into the applications are usually generated from "traces" captured from live systems, possibly filtered and post-processed to simulate exactly the interaction we want to see. It is sometimes useful to "recapture" from test-data instead of a live system, and when we capture things, we don't always know what attributes a subsequent test might actually want. To faithfully replay the interaction later we therefore need to preserve "as much as we can". We are aware that poking random things in sysfs can have rather "undesirable" consequences, so there is probably not much one can do with such an interface outside the scope of such testing scenarios. It is on the other hand very difficult to provide good testability without it. Cheers, Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
