On Thu, Jun 06, 2013 at 12:17:56PM +0100, Nick Dyer wrote: > Mark Brown wrote: > > If that's a big problem just put the data table in a section of the > > firmware (or a separate file that gets requested as a firmware). Or > > have the firmware be able to enumerate itself when asked. > That still would breach the NDA, I'm afraid. And there's hundreds of > existing versions of maXTouch chips already out there which don't have the > infrastructure in place to do what you describe. I'm sorry, this just doesn't seem plausible. The data is going to be on the running system and accessed via the kernel - as soon as people start using this back door they're going to be revealing what they're accessing and the information is going to be present in the binary blobs. You're only revealing that the parameters are present, not what they mean, and if it's a big concern then do something like strip down the data file that gets shipped in production to just the controls that are being accessed. Again, the fact that you have shipped this stuff doesn't make much difference here - you really should work with upstream on interfaces like this sooner rather than later otherwise you're going to have to cope with pushback. > If we expose every single parameter as a get/set as you suggest, we haven't > added anything that stops a binary of the wrong version doing something > stupid. We've just added a complex API to the same underlying thing, which > gains nothing. So this goes back to what I was saying before about the interface being badly designed - if the API you have to present is really this complex then you've got a big problem in kernel or out of kernel. > In practice, where there is a risk of the user mucking up their > configuration, the open-source user-space tools that we have released > provide an easy way to back up and restore the configuration in use, and > the kernel driver provides a way to load a known good configuration on > probe. The same configuration formats and tools are used across maXTouch > products on many platforms. So you're saying that this is all nice and consistent. If that's the case then there should be no problem putting at least the core bit that does the actual physical interaction with the device into the kernel.
Attachment:
signature.asc
Description: Digital signature
