Thierry Lelegard wrote: >> Copying in and out of kernel is not fun and eats >> a lot of your CPU. Which is quite useless. > > It is not a matter of performance, it is a matter of > operating system security and stability. > In the outlook that we can accept that fact that we can live with reduced performance. (Though i am not following your security viewpoint) > Access to a device is a matter of security, it needs > access to internal kernel structure, it needs user access > control. It must be in the kernel. > > Once you gain access to a DBV device, there is no security > involved in demuxing the TS. There is no *need* to implement > a software demux in the kernel. Consider, this view as though everything else is fine: What do you do about devices having HW filters ? Then you will need to implement them in userland, in your view, which brings in inconsistent userspace interfaces. > Concerning stability, the more code you put in the kernel, > the more potential bugs you get. Bugs in the kernel means > potential security breach, potential system hang or crash. > So, when there is no good security reason to put something > the kernel, you don't. > > This is what it done in microkernels such as Chorus, Mach or L4. You should look at Minix as well, but then the OS design is completely different. > I know, Linux is a monolithic kernel, not a microkernel. > But monolithic does not mean bloated. See Solaris or OpenVMS, > they are monolithic kernels, but they know when it is reasonable > to put code in the kernel and when it is not. > Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
