> > This project does NOTHING with device nodes or permissions what so ever. > > This project only uses the libusb API from an UNPRIVILEGED process. > > This project adds no privileged code, no daemons or service and no > code that needs to run with privilege. > > libsane is as responsible for device permissions and security as dd(1) > is. There is actually nothing that libsane does that can't already > be done by dd(1) directly on the device node or a bit of user compiled > C code linked to libusb can't do. > > There is no new issues that this project brings to the table that > don't already exist with libusb and ugen(7D). If ugen(7D) is broken > with respect to device allocation then PSARC 2005/187 caused that > breakage and needs to be fixed project CAN NOT fix that and should not > be held to fixing it. > Yes, fully agree. The above words tell the key points.
While it is good to see this case raised discussion about ugen(7D) related device allocation or object reuse issues, it is out of scope for this case to continue to discuss them. Because this case can neither contribute to the issue nor make it worse. We now know it should be a seperate project to investigate the ugen(7D) issue. USB dev. team is happy to work with people to get ugen investigation done. I am working on USB and I myself would like to contribute to this task. Let's just focus on the interfaces/issues within this case scope. Solaris users are expecting scanner support, we engineers should move forward to make this feature done, and also investigate the ugen issue in parelle. Thanks, Colin
