While the previous patches were purely infrastructure, this patch[...]
actually adds the code using it: mem1394.
There are some open questions on a few things, maybe someone can help
out there.
+ /* this is a bit icky. I think I'll want to create a
+ * "struct hpsb_node_class_interface" that you register
+ * with nodemgr.c instead of registering the "struct class_interface"
+ * directly. It would wrap around the "struct class_interface"
+ * and handle things like this.
+ *
+ * This means it would call the node_class_interface's
+ * - "add" method whenever the device is fully there, and an
+ * - "update" method when it survived a bus reset, and the
+ * - "remove" method when it went away, also taking care of
+ * debouncing, which the mem1394 interface currently doesn't handle.
+ * But I need advice on this. It'll probably works this way
+ * but most likely not once this interface stuff gets more
+ * use; I can imagine using it for scanners instead of raw1394
+ * so that the kernel can validate that a user can only
+ * access a certain scanner and not all 1394 devices on the bus.
+ * In other words some 'raw1394intf' instead of 'raw1394' which[...]
+ * creates one character device per ieee1394 node for finer
+ * grained access control.
+ * That would definitely want to have debouncing etc.
+ *
+ * However, I don't fully understand the states node_entries go
+ * through yet, so I'm not sure this should even be here!
+ * Maybe it should be in open? But then the device could go
+ * into limbo when it is already opened...
+ *
+ * Similarly, what happens if a node is suspended?
+ */