On Thu, Mar 3, 2011 at 18:38, Thomas Egerer <thomas.egerer@xxxxxxxxxxx> wrote: > 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? Sure, sounds fine to have that. Maybe just use the interface for: udevadm info -a and replace: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=udev/udevadm-info.c;h=4510f4aa907dc56a22544564ec1e10045046bf61;hb=HEAD#l34 with the same patch, and check that all works fine. > 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. Sounds all fine, just be careful. :) Kay -- 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
