[EMAIL PROTECTED] wrote: > > Just got around to having a look @ the V4 API code in CVS and was well > impressed at how far we have got since I spoke last : ) > I see that we have decided on using the original V4 API as intended by > Johannes/Holger rather than Michael's with different output devices. > Having had a quick look at the code, I cannot see where we perform checks > on the allocation of feeds/filters. What I mean is there doesn't seem to > be any code that checks to ensure that there are enough underlying h/w > filters left to allocate when someone open's up an fd on the demux device. > If it is there, then could you point me in the right direction - thanks : ) > > This leads me into the next point/question regarding output devices. > Wouldn't it be better to have output demux devices such as PID filter, > recording filter, section filter, decoder feed with each one allocated a > different minor number. Then when the user app came to open up an fd on > this device, we would know immediately if we had enough > resources/filters/feeds left to allow the "open" syscall to succeed. At > the moment we open up an fd, but we don't know what the underlying usage of > it is going to be until we perform one of the demux IOCTLs to setup a > feed/filter. Only here, is when we know whether we can actually get a > handle to a feed/filter. Not really that elegant is it?
Well, this is the way we designed it. It fits our application's use of resources -- we don't grab them in advance to "reserve" them, we allocate resources when we need them and release them when we are done with them. So it does not make a difference if open() fails or ioctl(SET_FILTER) fails. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
