> > Userspace tells the driver what it should do and the driver decides how to do it. > That's how it works. Sounds a little religious. Not sure if you've been listening.. > >> And for us it is even more reusable, because we can run the >> same thing on a standalone 'OS' (no OS really) and for example RTEMS. > > That is never a consideration for linux. Hardware abstraction layers are not > allowed. Blame Linus, not me, although I completely agree with him on this. > This is new to me. What should be the reason not to abstract hardware? To give people a coding job? >> So for the various OS specifics, we only have one video acquisition >> driver which has no knowledge of the attached sensor. All generic v4l2 >> properties again are tunneled through userspace to the "sensor daemon". >> I still don't see what is (technically) wrong with that. > > It's the tunneling to a sensor daemon that is wrong. You can write a sensor > driver as a V4L subdevice driver and it is reusable by any 'video acquisition; > driver (aka V4L2 bridge/platform driver) without going through userspace and > requiring userspace daemons. > > It's the tunneling to a sensor daemon that is wrong. You can write a sensor > driver as a V4L subdevice driver and it is reusable by any 'video acquisition; > driver (aka V4L2 bridge/platform driver) without going through userspace and > requiring userspace daemons. You keep saying it is wrong, but I have so far seen no technically firm argument. Please tell me why. > >> For me, it works like a driver, plus it is way more flexible as I don't >> have to go through ioctls for special sensor properties. > > You still have to go through the kernel to set registers. That's just as > expensive as an ioctl. > Not sure if you understand: I do not have to implement or generate ioctl handlers and call them. This is definitely less expensive in terms of coding. All the register access is handled *automatically* using the HW description layer. > > Sure, no problem. It's open source after all. Just be aware that all the > maintenance effort is for you as long as you remain out of tree. > We have to do this anyhow. But we'd prefer to do it the way that requires least maintenance as described. We need to have a *solution*. Not some academic hack that is "not wrong". I think we can end the discussion here. I was hoping for more technically valuable input, really. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
