> You know - I'm a bit confused. Somebody are pointing on double > data copying (userspace networked daemon -> kernel -> application) > issue and another one warn me to not start network connection > from the kernel. But if it works for NFS or CIFS then it should not > be so weaky, isn't it? And then you want to add multicast, or SSL or some other transport layer, and so on. You can do it - but in the case of DVB it's really probably not the overall way to go. > What exactly vtuner aproach does so hackish (other then exposing > DVB internals, what is every time made if virtualization support is developing)? Exposing DVB internals is also not good - it creates an API which locks out future trivial changes to that API because it might break your stuff. Also you are trying to fake distributed network in the wrong place so faking basically synchronous interfaces with undefined network behaviour and time lines. > The code itself no need to patch any line of vanilla kernel source, it even > doesn't change any processing of the rest of kernel, it is very simple > driver/code/whatever. That's not a measure of whether something is a good idea, more of the cleanness of the core code. Fix the userspace bits that need fixing, or use ones that don't - in the longer term that will be a bigger win by far. Alan -- 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
