Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 07.12.2011 22:48, Patrick Dickey wrote: > 4 (and the reason I decided to chime in here). This email sums > everything up. Mark is pointing out that someone may want to use this in > a non LAN setting, and they may/will have problems due to the Internet > (and their specific way of accessing it). Andreas is arguing that it's > not the case. I'm sorry if I was unclear, but I'm not doing that. Contrary, I'm sure that people using dreamtuner (which uses vtunerc from userspace) over the Internet will run into problems if they can't provide the necessary bandwidth. What I'm trying to point out is that dreamtuner is not trying to solve these problems, because it specifically has been designed for a different purpose. > I have to side with Mark on this one, solely because if I knew that it > would work, I'd use it to watch television when I'm traveling (as some > places don't carry the same channels that I have at home). Yes, if you knew. But you wouldn't, because when travelling, it's unlikely that you could guarantee the necessary bandwidth all the time. I'd highly recommend you and Mark to use a different solution than dreamtuner for your use cases. > So, I would > prove Mark's point. I wonder how. > Andreas, you said that "virtually EVERY (emphasis mine) user of it will > use it on a LAN". "Virtually" implies almost all-- NOT ALL. So, unless > there's some restriction in the application, which prevents it from > being used over the Internet, you can't guarantee that Mark's issues > aren't valid. It may or may not work for some people. There's no need to artificially restrict dreamtuner to hosts on a LAN (which would be impossible anyway). > If as HoP pointed out in another reply on this thread, there's no kernel > patching required, then I suggest that you keep on developing it as a > userspace application. There's no law/rule/anything that says you can't > install your own driver in the kernel. It just won't be supported > upstream. That just means more work for you, if you want the > application to continue working in the future. Truthfully, that has it's > upsides also. If you find out about a way to improve the transmission, > you don't have to wait (and hope) that it gets included in the kernel. > You can include it in your driver. FWIW, It's HoP's code. I'm not developing it. Although you seem to have noticed that all networking happens in userspace, you're still discussing networking issues, which may or may not be issues of dreamtuner, but provably not of vtunerc, which just relays DVB driver calls to userspace. Since the topic is about the inclusion of vtunerc, not dreamtuner, such stuff really is totally off-topic, but unfortunately got brought up again and again. You don't drive a formula one car or a truck if you want to have a picnic with your family, do you? I guess you'd rather choose the right tool for this task. So should you do if you want to stream television over the net. People complaining that they can't transport their family in a formula one car don't help anybody. Still both formula one cars and trucks may be useful for other purposes. You're free to replace dreamtuner with your superior tool solving all of Mark's issues, even without the need to change vtunerc. So far many people jumped into this discussion, but virtually(!) nobody took the time to understand what vtunerc actually does by looking at the code or at the various links HoP provided. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
2011/12/7 Patrick Dickey : > On 12/07/2011 08:01 AM, Andreas Oberritter wrote: >> On 07.12.2011 14:49, Mark Brown wrote: >>> On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote: On 06.12.2011 15:19, Mark Brown wrote: >>> > Your assertatation that applications should ignore the underlying > transport (which seems to be a big part of what you're saying) isn't > entirely in line with reality. >>> Did you notice that we're talking about a very particular application? >>> >>> *sigh* >>> VoIP really is totally off-topic. The B in DVB stands for broadcast. There's only one direction in which MPEG payload is to be sent (using RTP for example). You can't just re-encode the data on the fly without loss of information. >>> >>> This is pretty much exactly the case for VoIP some of the time (though >>> obviously bidirectional use cases are rather common there's things like >>> conferencing). I would really expect similar considerations to apply >>> for video content as they certainly do in videoconferencing VoIP >>> applications - if the application knows about the network it can tailor >>> what it's doing to that network. >>> >>> For example, if it is using a network with a guaranteed bandwidth it can >>> assume that bandwidth. If it knows something about the structure of the >>> network it may be able to arrange to work around choke points. >>> Depending on the situation even something lossy may be the answer - if >>> it's the difference between working at all and not working then the cost >>> may be worth it. >> >> Once and for all: We have *not* discussed a generic video streaming >> application. It's only, I repeat, only about accessing a remote DVB API >> tuner *as if it was local*. No data received from a satellite, cable or >> terrestrial DVB network shall be modified by this application! >> >> Virtually *every* user of it will use it in a LAN. >> >> It can't be so hard to understand. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > I tend to stay out of these discussions, since like a couple of others, > I'm not a kernel developer (or hacker). However, I wanted to chime in > with my two cents here. > > 1. I agree that it's not acceptable to "NACK" purely for philosophical > reasons (except when it's a clear violation of a license--be that open > source or closed source (since we don't want to open ourselves up to > lawsuits). > > 2. In this case, there have been technical reasons provided. Granted > the developers (and people who are pro-inclusion) don't feel those are > justified, but they have been cited. > > 3. You'll catch more flies with honey than vinegar (in other words, > fighting with the person(s) who maintain the project will most > definitely *not* get your code included). Yes, that I think we all know. But some problem is that the arguments against it are very weak. Believe me I would prefer to work on all hints which kernel hackers gave me after code reviewing and not to be member of flamewar. > 4 (and the reason I decided to chime in here). This email sums > everything up. Mark is pointing out that someone may want to use this in > a non LAN setting, and they may/will have problems due to the Internet > (and their specific way of accessing it). Andreas is arguing that it's > not the case. > > I have to side with Mark on this one, solely because if I knew that it > would work, I'd use it to watch television when I'm traveling (as some > places don't carry the same channels that I have at home). So, I would > prove Mark's point. Some features are designed for LAN use. I think nobody wants to use SMBFS over Internet. But in LAN it works perfectly stable. > Andreas, you said that "virtually EVERY (emphasis mine) user of it will > use it on a LAN". "Virtually" implies almost all-- NOT ALL. So, unless > there's some restriction in the application, which prevents it from > being used over the Internet, you can't guarantee that Mark's issues > aren't valid. > > If as HoP pointed out in another reply on this thread, there's no kernel > patching required, then I suggest that you keep on developing it as a > userspace application. I guess you mean by "developing like userspave app" variant of development kernel driver out of tree. > There's no law/rule/anything that says you can't > install your own driver in the kernel. It just won't be supported > upstream. That just means more work for you, if you want the > application to continue working in the future. Truthfully, that has it's > upsides also. If you find out about a way to improve the transmission, > you don't have to wait (and hope) that it gets included in the kernel. > You can include it in your driver. As you stated already - maintaining kernel-space code out of kernel tree is much difficult. If anybody did any change
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 12/07/2011 08:01 AM, Andreas Oberritter wrote: > On 07.12.2011 14:49, Mark Brown wrote: >> On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote: >>> On 06.12.2011 15:19, Mark Brown wrote: >> Your assertatation that applications should ignore the underlying transport (which seems to be a big part of what you're saying) isn't entirely in line with reality. >> >>> Did you notice that we're talking about a very particular application? >> >> *sigh* >> >>> VoIP really is totally off-topic. The B in DVB stands for broadcast. >>> There's only one direction in which MPEG payload is to be sent (using >>> RTP for example). You can't just re-encode the data on the fly without >>> loss of information. >> >> This is pretty much exactly the case for VoIP some of the time (though >> obviously bidirectional use cases are rather common there's things like >> conferencing). I would really expect similar considerations to apply >> for video content as they certainly do in videoconferencing VoIP >> applications - if the application knows about the network it can tailor >> what it's doing to that network. >> >> For example, if it is using a network with a guaranteed bandwidth it can >> assume that bandwidth. If it knows something about the structure of the >> network it may be able to arrange to work around choke points. >> Depending on the situation even something lossy may be the answer - if >> it's the difference between working at all and not working then the cost >> may be worth it. > > Once and for all: We have *not* discussed a generic video streaming > application. It's only, I repeat, only about accessing a remote DVB API > tuner *as if it was local*. No data received from a satellite, cable or > terrestrial DVB network shall be modified by this application! > > Virtually *every* user of it will use it in a LAN. > > It can't be so hard to understand. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html I tend to stay out of these discussions, since like a couple of others, I'm not a kernel developer (or hacker). However, I wanted to chime in with my two cents here. 1. I agree that it's not acceptable to "NACK" purely for philosophical reasons (except when it's a clear violation of a license--be that open source or closed source (since we don't want to open ourselves up to lawsuits). 2. In this case, there have been technical reasons provided. Granted the developers (and people who are pro-inclusion) don't feel those are justified, but they have been cited. 3. You'll catch more flies with honey than vinegar (in other words, fighting with the person(s) who maintain the project will most definitely *not* get your code included). 4 (and the reason I decided to chime in here). This email sums everything up. Mark is pointing out that someone may want to use this in a non LAN setting, and they may/will have problems due to the Internet (and their specific way of accessing it). Andreas is arguing that it's not the case. I have to side with Mark on this one, solely because if I knew that it would work, I'd use it to watch television when I'm traveling (as some places don't carry the same channels that I have at home). So, I would prove Mark's point. Andreas, you said that "virtually EVERY (emphasis mine) user of it will use it on a LAN". "Virtually" implies almost all-- NOT ALL. So, unless there's some restriction in the application, which prevents it from being used over the Internet, you can't guarantee that Mark's issues aren't valid. If as HoP pointed out in another reply on this thread, there's no kernel patching required, then I suggest that you keep on developing it as a userspace application. There's no law/rule/anything that says you can't install your own driver in the kernel. It just won't be supported upstream. That just means more work for you, if you want the application to continue working in the future. Truthfully, that has it's upsides also. If you find out about a way to improve the transmission, you don't have to wait (and hope) that it gets included in the kernel. You can include it in your driver. Sorry for butting into this. You're free to flame or ignore me, as you choose. Have a great day:) Patrick. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 07.12.2011 17:10, Mark Brown wrote: > You're talking about a purely software defined thing that goes in the > kernel - it pretty much has to be able to scale to other applications > even if some of the implementation is left for later. Once things like > this get included in the kernel they become part of the ABI and having > multiple specific things ends up being a recipie for confusion as users > have to work out which of the options is most appropriate for their > application. And to repeat myself once more: No networking is to be perfomed by the kernel in vtunerc. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 07.12.2011 17:10, Mark Brown wrote: > a simple loopback in the style of FUSE which > bounces the kernel APIs up to userspace for virtual drivers would make > sense. That's exactly what vtunerc is. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Wed, Dec 07, 2011 at 03:01:18PM +0100, Andreas Oberritter wrote: > Once and for all: We have *not* discussed a generic video streaming > application. It's only, I repeat, only about accessing a remote DVB API > tuner *as if it was local*. No data received from a satellite, cable or > terrestrial DVB network shall be modified by this application! > Virtually *every* user of it will use it in a LAN. > It can't be so hard to understand. You're talking about a purely software defined thing that goes in the kernel - it pretty much has to be able to scale to other applications even if some of the implementation is left for later. Once things like this get included in the kernel they become part of the ABI and having multiple specific things ends up being a recipie for confusion as users have to work out which of the options is most appropriate for their application. Really this feels like the pattern we've got with audio where we restrict the drivers to driving hardware and there's a userspace which wraps that and can also dispatch to a userspace implementation without applications worrying about it. Perhaps given the current entirely in kernel implementation a simple loopback in the style of FUSE which bounces the kernel APIs up to userspace for virtual drivers would make sense. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 07.12.2011 14:49, Mark Brown wrote: > On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote: >> On 06.12.2011 15:19, Mark Brown wrote: > >>> Your assertatation that applications should ignore the underlying >>> transport (which seems to be a big part of what you're saying) isn't >>> entirely in line with reality. > >> Did you notice that we're talking about a very particular application? > > *sigh* > >> VoIP really is totally off-topic. The B in DVB stands for broadcast. >> There's only one direction in which MPEG payload is to be sent (using >> RTP for example). You can't just re-encode the data on the fly without >> loss of information. > > This is pretty much exactly the case for VoIP some of the time (though > obviously bidirectional use cases are rather common there's things like > conferencing). I would really expect similar considerations to apply > for video content as they certainly do in videoconferencing VoIP > applications - if the application knows about the network it can tailor > what it's doing to that network. > > For example, if it is using a network with a guaranteed bandwidth it can > assume that bandwidth. If it knows something about the structure of the > network it may be able to arrange to work around choke points. > Depending on the situation even something lossy may be the answer - if > it's the difference between working at all and not working then the cost > may be worth it. Once and for all: We have *not* discussed a generic video streaming application. It's only, I repeat, only about accessing a remote DVB API tuner *as if it was local*. No data received from a satellite, cable or terrestrial DVB network shall be modified by this application! Virtually *every* user of it will use it in a LAN. It can't be so hard to understand. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote: > On 06.12.2011 15:19, Mark Brown wrote: > > Your assertatation that applications should ignore the underlying > > transport (which seems to be a big part of what you're saying) isn't > > entirely in line with reality. > Did you notice that we're talking about a very particular application? *sigh* > VoIP really is totally off-topic. The B in DVB stands for broadcast. > There's only one direction in which MPEG payload is to be sent (using > RTP for example). You can't just re-encode the data on the fly without > loss of information. This is pretty much exactly the case for VoIP some of the time (though obviously bidirectional use cases are rather common there's things like conferencing). I would really expect similar considerations to apply for video content as they certainly do in videoconferencing VoIP applications - if the application knows about the network it can tailor what it's doing to that network. For example, if it is using a network with a guaranteed bandwidth it can assume that bandwidth. If it knows something about the structure of the network it may be able to arrange to work around choke points. Depending on the situation even something lossy may be the answer - if it's the difference between working at all and not working then the cost may be worth it. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi Andreas [...] >>> You don't need to wait for write-only operations. Basically all demux >>> ioctls are write-only. Since vtunerc is using dvb-core's software demux >>> *locally*, errors for invalid arguments etc. will be returned as usual. >>> >>> What's left is one call to FE_SET_FRONTEND for each frequency to tune >>> to, and one FE_READ_STATUS for each time the lock status is queried. >>> Note that one may use FE_GET_EVENT instead of FE_READ_STATUS to get >>> notified of status changes asynchronously if desired. >>> >>> Btw.: FE_SET_FRONTEND doesn't block either, because the driver callback >>> is called from a dvb_frontend's *local* kernel thread. >> >> Still, vtunerc waits for write operations: >> >> http://code.google.com/p/vtuner/source/browse/vtunerc_proxyfe.c?repo=linux-driver#285 >> >> No matter if they are read or write, all of them call this function: >> >> http://code.google.com/p/vtuner/source/browse/vtunerc_ctrldev.c?repo=linux-driver#390 >> >> That has a wait_event inside that function, as everything is directed to >> the userspace. > > Please, stop writing such bullshit! Just before the call to wait_event > there's code to return from the function if waiting has not been requested. > >> This is probably the way Florian found to return the errors returned by >> the ioctls. This driver is synchronous, with simplifies it, at the lack of >> performance. > > The fix is easy: set the third parameter to 0. A DVB application doesn't > need to know whether SET_VOLTAGE etc. succeeded or not, because it won't > get any feedback from the switch. If tuning fails, it has to retry > anyway, even if all ioctls returned 0. > >> Ok, the driver could be smarter than that, and some heuristics could be >> added into it, in order to foresee the likely error code, returning it >> in advance, and then implementing some asynchronous mechanism that would >> handle the error later, but that would be complex and may still introduce >> some bad behaviors. > > There's no need to handle errors that don't occur. > > Nobody said that the implementation of vtunerc was perfect. I've already > listed many things that need to be changed in order to even consider it > for merging. Exactly that was an intention for my first RFC - to get driver reviewed by kernel hackers and enhance/fixe it to prepare it for merging. I'm going to address all your findings during Xmass, so hopefully I will spam here again after New Year :-) I very appreciate your POV which helped me stay remembering it is not way to the wall. Thanks Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Tue, Dec 6, 2011 at 7:49 PM, Mark Brown wrote: > On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote: >> On 06.12.2011 12:21, Mark Brown wrote: >> > On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote: > >> >> Are you serious? Lower networking layers should be transparent to the >> >> upper layers. You don't implement VPN or say TCP in all of your >> >> applications, do you? These are just some more made-up arguments which >> >> don't have anything to do with the use cases I explained earlier. > >> > For real time applications it does make a big difference - decisions >> > taken at the application level can greatly impact end application >> > performance. For example with VoIP on a LAN you can get great audio > >> Can you please explain how this relates to the topic we're discussing? > > Your assertatation that applications should ignore the underlying > transport (which seems to be a big part of what you're saying) isn't > entirely in line with reality. A point to be noted: DVB itself is a network protocol; If you have a satellite network, most likely it is a DVB network where the whole network packets are encapsulated within DVB (MPEG TS) packets. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Tue, Dec 6, 2011 at 8:36 PM, Mauro Carvalho Chehab wrote: > On 06-12-2011 12:38, Andreas Oberritter wrote: >> >> On 06.12.2011 15:13, Mauro Carvalho Chehab wrote: >>> >>> O_NONBLOCK >>> When opening a FIFO with O_RDONLY or O_WRONLY set: >> >> This does not apply. >> >> [...] >> >>> When opening a block special or character special file that supports >>> non-blocking opens: >>> >>> If O_NONBLOCK is set, the open() function shall return without >>> blocking for the device to be ready or available. Subsequent behavior of >>> the device is device-specific. >> >> >> This is the important part: >> - It specifies the behaviour of open(), not ioctl(). I don't see a >> reason why open should block with vtunerc. >> - Read again: "Subsequent behavior of the device is device-specific." >> >>> If O_NONBLOCK is clear, the open() function shall block the >>> calling thread until the device is ready or available before returning. >>> >>> Otherwise, the behavior of O_NONBLOCK is unspecified. >>> >>> Basically, syscall should not block waiting for some data to be read (or >>> written). >> >> >> That's because open() does not read or write. >> >>> The ioctl definition defines [EAGAIN] error code, if, for any reason, an >>> ioctl would block. >> >> >> Fine. >> >>> Btw, the vtunerc doesn't handle O_NONBLOCK flag. For each DVB ioctl, for >>> example >>> read_snr[1], it calls wait_event_interruptible()[2], even if the >>> application opens >>> it with O_NONBLOCK flag. So, it is likely that non-blocking-mode >>> applications >>> will break. >> >> >> Of course, read operations must wait until the value read is available >> or an error (e.g. timeout, i/o error) occurs. Whether it's an i2c >> transfer, an usb transfer or a network transfer doesn't make a >> difference. Every transfer takes a nonzero amount of time. > > > Yes, posix is not 100% clear about what "non block" means for ioctl's, but > waiting for an event is clearly a block condition. This is different than > doing something like mdelay() (or even mleep()) in order to wait for an > specific amount of time for an operation to complete. > > A vtunerc => daemon => network transfer =>daemon => vtunerc is a block > condition, > as the network may return in a few ms or may not return and a long > timeout at the daemon would give an error. Also, as the daemon may be > swapped > to disk (as the daemon runs on userspace), this may even involve other > blocking operations at the block layer. > > >> As Honza already demonstrated, in a typical LAN setup, this takes only >> few milliseconds, which with fast devices may even be faster than some >> slow local devices using many delays in their driver code. >> >> If an application breaks because of that, then it's a bug in the >> application which may as well be triggered by a local driver and thus >> needs to be fixed anyway. > > > It is not a bug in the application. It requested a non-block mode. The > driver > is working in block mode instead. It is a driver's bug. > > Mauro, if the network is broken, any application using the network will break. No specially designed protocol will fix that. >>> >>> >>> A high delay network (even a congested one) is not broken, if it can >>> still provide the throughput required by the application, and a >>> latency/QoS >>> that would fit. >> >> >> Then neither vtunerc nor any other application will break. Fine. >> If you want to enforce strict maximum latencies, you can do that in the userspace daemon using the vtunerc interface. It has all imaginable possibilities to control data flow over the network and to return errors to vtunerc. >>> >>> >>> Yes, you can do anything you want at the userspace daemon, but the >>> non-userspace daemon aware applications will know nothing about it, and >>> this is the flaw on this design: Applications can't negotiate what >>> network >>> parameters are ok or not for its usecase. >> >> >> How do you negotiate network parameters with your ISP and all involved >> parties on the internet on the way from your DSL line to some other >> peer? Let me answer it: You don't. > > > TCP flow control mechanisms, RSVP, MPLS, IP QoS flags, ICMP messages, etc. > You would need a Data Link Protocol, which would be PPP of some form http://en.wikipedia.org/wiki/Point-to-Point_Protocol I don't think, you have much to negotiate there. Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 06-12-2011 12:38, Andreas Oberritter wrote: On 06.12.2011 15:13, Mauro Carvalho Chehab wrote: O_NONBLOCK When opening a FIFO with O_RDONLY or O_WRONLY set: This does not apply. [...] When opening a block special or character special file that supports non-blocking opens: If O_NONBLOCK is set, the open() function shall return without blocking for the device to be ready or available. Subsequent behavior of the device is device-specific. This is the important part: - It specifies the behaviour of open(), not ioctl(). I don't see a reason why open should block with vtunerc. - Read again: "Subsequent behavior of the device is device-specific." If O_NONBLOCK is clear, the open() function shall block the calling thread until the device is ready or available before returning. Otherwise, the behavior of O_NONBLOCK is unspecified. Basically, syscall should not block waiting for some data to be read (or written). That's because open() does not read or write. The ioctl definition defines [EAGAIN] error code, if, for any reason, an ioctl would block. Fine. Btw, the vtunerc doesn't handle O_NONBLOCK flag. For each DVB ioctl, for example read_snr[1], it calls wait_event_interruptible()[2], even if the application opens it with O_NONBLOCK flag. So, it is likely that non-blocking-mode applications will break. Of course, read operations must wait until the value read is available or an error (e.g. timeout, i/o error) occurs. Whether it's an i2c transfer, an usb transfer or a network transfer doesn't make a difference. Every transfer takes a nonzero amount of time. Yes, posix is not 100% clear about what "non block" means for ioctl's, but waiting for an event is clearly a block condition. This is different than doing something like mdelay() (or even mleep()) in order to wait for an specific amount of time for an operation to complete. A vtunerc => daemon => network transfer =>daemon => vtunerc is a block condition, as the network may return in a few ms or may not return and a long timeout at the daemon would give an error. Also, as the daemon may be swapped to disk (as the daemon runs on userspace), this may even involve other blocking operations at the block layer. As Honza already demonstrated, in a typical LAN setup, this takes only few milliseconds, which with fast devices may even be faster than some slow local devices using many delays in their driver code. If an application breaks because of that, then it's a bug in the application which may as well be triggered by a local driver and thus needs to be fixed anyway. It is not a bug in the application. It requested a non-block mode. The driver is working in block mode instead. It is a driver's bug. Mauro, if the network is broken, any application using the network will break. No specially designed protocol will fix that. A high delay network (even a congested one) is not broken, if it can still provide the throughput required by the application, and a latency/QoS that would fit. Then neither vtunerc nor any other application will break. Fine. If you want to enforce strict maximum latencies, you can do that in the userspace daemon using the vtunerc interface. It has all imaginable possibilities to control data flow over the network and to return errors to vtunerc. Yes, you can do anything you want at the userspace daemon, but the non-userspace daemon aware applications will know nothing about it, and this is the flaw on this design: Applications can't negotiate what network parameters are ok or not for its usecase. How do you negotiate network parameters with your ISP and all involved parties on the internet on the way from your DSL line to some other peer? Let me answer it: You don't. TCP flow control mechanisms, RSVP, MPLS, IP QoS flags, ICMP messages, etc. For a DVB API application it doesn't matter whether a tuning request fails with EIO because a USB device has been removed, a PCI device encountered an I2C error or because the vtuner userspace daemon returned an error. When you go to network, there are several errors that are transitory. For example, a dropped link may cause the routing protocol (RIP, BGP or whatever) to re-direct several routes (or, on a LAN, a spanning-tree re-negotiation), causing a temporary failure to deliver a few packets. All network-based application are written to consider temporary failures. I seriously doubt that, unless "consider" means "print an error and exit" or "all" means "some". Anyway, such temporary failures can be handled by the userspace daemon. This is fundamentally different than an application designed to talk directly with the hardware, where an error is generally fatal. Fatal or not, if you return a temporary error code like EAGAIN, for example, that's not the case. Do you recommend applications to just die if an ioctl fails? Network applications (Youtube, Skype, mplayer, you name it) have mechanisms to
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 06.12.2011 15:19, Rémi Denis-Courmont wrote: > Le mardi 6 décembre 2011 15:49:11 Andreas Oberritter, vous avez écrit : >> You don't need to wait for write-only operations. Basically all demux >> ioctls are write-only. Since vtunerc is using dvb-core's software demux >> *locally*, errors for invalid arguments etc. will be returned as usual. > > That's a limitation, not a feature. You misunderstood. > You should not transmit unwanted programs over the network, nor copy them to > kernel space. I agree. And nobody said that this would happen. The software demux receives pre-filtered data. Still the ioctls are local. Just a trigger to start or stop filters needs to be sent to the remote demux, just like a register setting would be needed for a local hardware demux. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 06.12.2011 15:20, Mauro Carvalho Chehab wrote: > On 06-12-2011 11:49, Andreas Oberritter wrote: >> On 06.12.2011 14:22, Mauro Carvalho Chehab wrote: >>> On 05-12-2011 22:07, HoP wrote: > I doubt that scan or w_scan would support it. Even if it supports, > that > would mean that, > for each ioctl that would be sent to the remote server, the error > code would > take 480 ms > to return. Try to calculate how many time w_scan would work with > that. The > calculus is easy: > see how many ioctl's are called by each frequency and multiply by the > number > of frequencies > that it would be seek. You should then add the delay introduced over > streaming the data > from the demux, using the same calculus. This is the additional time > over a > local w_scan. > > A grouch calculus with scandvb: to tune into a single DVB-C > frequency, it > used 45 ioctls. > Each taking 480 ms round trip would mean an extra delay of 21.6 > seconds. > There are 155 > possible frequencies here. So, imagining that scan could deal with > 21.6 > seconds of delay > for each channel (with it doesn't), the extra delay added by it is 1 > hour > (45 * 0.48 * 155). > > On the other hand, a solution like the one described by Florian would > introduce a delay of > 480 ms for the entire scan to happen, as only one data packet would be > needed to send a > scan request, and one one stream of packets traveling at 10GB/s would > bring > the answer > back. Andreas was excited by your imaginations and calculations, but not me. Now you again manifested you are not treating me as partner for discussion. Otherwise you should try to understand how-that-ugly-hack works. But you surelly didn't try to do it at all. How do you find those 45 ioctls for DVB-C tune? >>> >>> With strace. See how many ioctl's are called for each tune. Ok, perhaps >>> scandvb >>> is badly written, but if your idea is to support 100% of the >>> applications, you >>> should be prepared for badly written applications. >>> >>> $strace -e ioctl scandvb dvbc-teste >>> scanning dvbc-teste >>> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' >>> ioctl(3, FE_GET_INFO, 0x60a640) = 0 >>> initial transponder 57300 5217000 0 5 >> tune to: 57300:INVERSION_AUTO:5217000:FEC_NONE:QAM_256 >>> ioctl(3, FE_SET_FRONTEND, 0x7fff5f7f2cd0) = 0 >>> ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0 >>> ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0 >>> ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0 >>> ioctl(4, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0 >>> ioctl(5, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0 >>> ioctl(6, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0 >>> ioctl(7, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(8, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(9, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(10, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(11, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(12, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(13, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(14, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(15, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(16, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(17, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(18, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(19, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(20, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(21, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(22, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(23, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(24, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 >>> ioctl(4, DMX_STOP, 0x1) = 0 >>> ioctl(15, DMX_STOP, 0x1)= 0 >>> ioctl(11, DMX_STOP, 0x1)= 0 >>> ioctl(22, DMX_STOP, 0x1)= 0 >>> ioctl(17, DMX_STOP, 0x1)= 0 >>> ioctl(16, DMX_STOP, 0x1)= 0 >> >> You don't need to wait for write-only operations. Basically all demux >> ioctls are write-only. Since vtunerc is using dvb-core's software demux >> *locally*, errors for invalid arguments etc. will be returned as usual. >> >> What's left is one call to FE_SET_FRONTEND for each frequency to tune >> to, and one FE_READ_STATUS for each time the lock status is queried. >> Note that one may use FE_GET_EVENT instead of FE_READ_STATUS to get >> notified of status changes asynchronously if desired. >> >> Btw.: FE_SET_FRONTEND doesn't block either, because the driver callback >> is called from a dvb_frontend's *local* kernel thread. > > Still, vtunerc waits for write operations: > > http://code.google.com/p/vtuner/source/browse/vtunerc_proxyfe.c?repo=linux-driver#285 > > No matter if they are read or write, all of them call this function: > > http://code.google.com/p/vtuner/source/browse/vtunerc_ctrldev.c?repo=linux-driver#390 > > That has a wait_event inside that function, as everyt
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 06.12.2011 15:19, Mark Brown wrote: > On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote: >> On 06.12.2011 12:21, Mark Brown wrote: >>> On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote: > Are you serious? Lower networking layers should be transparent to the upper layers. You don't implement VPN or say TCP in all of your applications, do you? These are just some more made-up arguments which don't have anything to do with the use cases I explained earlier. > >>> For real time applications it does make a big difference - decisions >>> taken at the application level can greatly impact end application >>> performance. For example with VoIP on a LAN you can get great audio > >> Can you please explain how this relates to the topic we're discussing? > > Your assertatation that applications should ignore the underlying > transport (which seems to be a big part of what you're saying) isn't > entirely in line with reality. Did you notice that we're talking about a very particular application? VoIP really is totally off-topic. The B in DVB stands for broadcast. There's only one direction in which MPEG payload is to be sent (using RTP for example). You can't just re-encode the data on the fly without loss of information. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 06.12.2011 15:13, Mauro Carvalho Chehab wrote: > O_NONBLOCK > When opening a FIFO with O_RDONLY or O_WRONLY set: This does not apply. [...] > When opening a block special or character special file that supports > non-blocking opens: > > If O_NONBLOCK is set, the open() function shall return without > blocking for the device to be ready or available. Subsequent behavior of > the device is device-specific. This is the important part: - It specifies the behaviour of open(), not ioctl(). I don't see a reason why open should block with vtunerc. - Read again: "Subsequent behavior of the device is device-specific." > If O_NONBLOCK is clear, the open() function shall block the > calling thread until the device is ready or available before returning. > > Otherwise, the behavior of O_NONBLOCK is unspecified. > > Basically, syscall should not block waiting for some data to be read (or > written). That's because open() does not read or write. > The ioctl definition defines [EAGAIN] error code, if, for any reason, an > ioctl would block. Fine. > Btw, the vtunerc doesn't handle O_NONBLOCK flag. For each DVB ioctl, for > example > read_snr[1], it calls wait_event_interruptible()[2], even if the > application opens > it with O_NONBLOCK flag. So, it is likely that non-blocking-mode > applications > will break. Of course, read operations must wait until the value read is available or an error (e.g. timeout, i/o error) occurs. Whether it's an i2c transfer, an usb transfer or a network transfer doesn't make a difference. Every transfer takes a nonzero amount of time. As Honza already demonstrated, in a typical LAN setup, this takes only few milliseconds, which with fast devices may even be faster than some slow local devices using many delays in their driver code. If an application breaks because of that, then it's a bug in the application which may as well be triggered by a local driver and thus needs to be fixed anyway. >> Mauro, if the network is broken, any application using the network will >> break. No specially designed protocol will fix that. > > A high delay network (even a congested one) is not broken, if it can > still provide the throughput required by the application, and a latency/QoS > that would fit. Then neither vtunerc nor any other application will break. Fine. >> If you want to enforce strict maximum latencies, you can do that in the >> userspace daemon using the vtunerc interface. It has all imaginable >> possibilities to control data flow over the network and to return errors >> to vtunerc. > > Yes, you can do anything you want at the userspace daemon, but the > non-userspace daemon aware applications will know nothing about it, and > this is the flaw on this design: Applications can't negotiate what network > parameters are ok or not for its usecase. How do you negotiate network parameters with your ISP and all involved parties on the internet on the way from your DSL line to some other peer? Let me answer it: You don't. >> For a DVB API application it doesn't matter whether a tuning >> request fails with EIO because a USB device has been removed, a PCI >> device encountered an I2C error or because the vtuner userspace daemon >> returned an error. > > When you go to network, there are several errors that are transitory. > For example, > a dropped link may cause the routing protocol (RIP, BGP or whatever) to > re-direct > several routes (or, on a LAN, a spanning-tree re-negotiation), causing a > temporary > failure to deliver a few packets. All network-based application are written > to consider temporary failures. I seriously doubt that, unless "consider" means "print an error and exit" or "all" means "some". Anyway, such temporary failures can be handled by the userspace daemon. > This is fundamentally different than an application designed to talk > directly with > the hardware, where an error is generally fatal. Fatal or not, if you return a temporary error code like EAGAIN, for example, that's not the case. Do you recommend applications to just die if an ioctl fails? Btw.: How do you handle firmware uploads via I2C in non-blocking mode? Should applications always fail if a firmware upload that takes longer than some ms, e.g. when tuning to a different delivery system or when the firmware is yet to be loaded before the first ioctl may run? Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 06-12-2011 11:49, Andreas Oberritter wrote: On 06.12.2011 14:22, Mauro Carvalho Chehab wrote: On 05-12-2011 22:07, HoP wrote: I doubt that scan or w_scan would support it. Even if it supports, that would mean that, for each ioctl that would be sent to the remote server, the error code would take 480 ms to return. Try to calculate how many time w_scan would work with that. The calculus is easy: see how many ioctl's are called by each frequency and multiply by the number of frequencies that it would be seek. You should then add the delay introduced over streaming the data from the demux, using the same calculus. This is the additional time over a local w_scan. A grouch calculus with scandvb: to tune into a single DVB-C frequency, it used 45 ioctls. Each taking 480 ms round trip would mean an extra delay of 21.6 seconds. There are 155 possible frequencies here. So, imagining that scan could deal with 21.6 seconds of delay for each channel (with it doesn't), the extra delay added by it is 1 hour (45 * 0.48 * 155). On the other hand, a solution like the one described by Florian would introduce a delay of 480 ms for the entire scan to happen, as only one data packet would be needed to send a scan request, and one one stream of packets traveling at 10GB/s would bring the answer back. Andreas was excited by your imaginations and calculations, but not me. Now you again manifested you are not treating me as partner for discussion. Otherwise you should try to understand how-that-ugly-hack works. But you surelly didn't try to do it at all. How do you find those 45 ioctls for DVB-C tune? With strace. See how many ioctl's are called for each tune. Ok, perhaps scandvb is badly written, but if your idea is to support 100% of the applications, you should be prepared for badly written applications. $strace -e ioctl scandvb dvbc-teste scanning dvbc-teste using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' ioctl(3, FE_GET_INFO, 0x60a640) = 0 initial transponder 57300 5217000 0 5 tune to: 57300:INVERSION_AUTO:5217000:FEC_NONE:QAM_256 ioctl(3, FE_SET_FRONTEND, 0x7fff5f7f2cd0) = 0 ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0 ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0 ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0 ioctl(4, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0 ioctl(5, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0 ioctl(6, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0 ioctl(7, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(8, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(9, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(10, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(11, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(12, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(13, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(14, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(15, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(16, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(17, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(18, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(19, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(20, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(21, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(22, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(23, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(24, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(4, DMX_STOP, 0x1) = 0 ioctl(15, DMX_STOP, 0x1)= 0 ioctl(11, DMX_STOP, 0x1)= 0 ioctl(22, DMX_STOP, 0x1)= 0 ioctl(17, DMX_STOP, 0x1)= 0 ioctl(16, DMX_STOP, 0x1)= 0 You don't need to wait for write-only operations. Basically all demux ioctls are write-only. Since vtunerc is using dvb-core's software demux *locally*, errors for invalid arguments etc. will be returned as usual. What's left is one call to FE_SET_FRONTEND for each frequency to tune to, and one FE_READ_STATUS for each time the lock status is queried. Note that one may use FE_GET_EVENT instead of FE_READ_STATUS to get notified of status changes asynchronously if desired. Btw.: FE_SET_FRONTEND doesn't block either, because the driver callback is called from a dvb_frontend's *local* kernel thread. Still, vtunerc waits for write operations: http://code.google.com/p/vtuner/source/browse/vtunerc_proxyfe.c?repo=linux-driver#285 No matter if they are read or write, all of them call this function: http://code.google.com/p/vtuner/source/browse/vtunerc_ctrldev.c?repo=linux-driver#390 That has a wait_event inside that function, as everything is directed to the userspace. This is probably the way Florian found to return the errors returned by the ioctls. This driver is synchronous, with simplifies it, at the lack of performance. Ok, the driver could be smarter than that, and some heuristics could be added into it, in order to foresee the likely error code, returning it in advance, and then implementing some asynchronous mechanism that would handle the error later, but that would be complex and may still introduce some bad behaviors. Regards, Mauro. -- To unsubscribe from
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Le mardi 6 décembre 2011 15:49:11 Andreas Oberritter, vous avez écrit : > You don't need to wait for write-only operations. Basically all demux > ioctls are write-only. Since vtunerc is using dvb-core's software demux > *locally*, errors for invalid arguments etc. will be returned as usual. That's a limitation, not a feature. You should not transmit unwanted programs over the network, nor copy them to kernel space. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote: > On 06.12.2011 12:21, Mark Brown wrote: > > On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote: > >> Are you serious? Lower networking layers should be transparent to the > >> upper layers. You don't implement VPN or say TCP in all of your > >> applications, do you? These are just some more made-up arguments which > >> don't have anything to do with the use cases I explained earlier. > > For real time applications it does make a big difference - decisions > > taken at the application level can greatly impact end application > > performance. For example with VoIP on a LAN you can get great audio > Can you please explain how this relates to the topic we're discussing? Your assertatation that applications should ignore the underlying transport (which seems to be a big part of what you're saying) isn't entirely in line with reality. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 06-12-2011 11:35, Andreas Oberritter wrote: On 06.12.2011 14:10, Mauro Carvalho Chehab wrote: On 06-12-2011 10:01, Andreas Oberritter wrote: On 06.12.2011 12:18, Mark Brown wrote: On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote: On 05.12.2011 21:55, Alan Cox wrote: The USB case is quite different because your latency is very tightly bounded, your dead device state is rigidly defined, and your loss of device is accurately and immediately signalled. Quite different. How can usbip work if networking and usb are so different and what's so different between vtunerc and usbip, that made it possible to put usbip into drivers/staging? USB-IP is a hack that will only work well on a tightly bounded set of networks - if you run it over a lightly loaded local network it can work adequately. This starts to break down as you vary the network configuration. I see. So it has problems that vtunerc doesn't have. The vtunerc has the same issues. High latency (due to high loads, high latency links or whatever) affects it badly, and may cause application breakages if if the device is opened are using O_NONBLOCK mode [1]. O_NONBLOCK doesn't mean that an ioctl must consume zero time. It just means that it should return instead of waiting for (more) data to become available or writeable. O_NONBLOCK means (http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html#tag_16_412): O_NONBLOCK When opening a FIFO with O_RDONLY or O_WRONLY set: If O_NONBLOCK is set, an open() for reading-only shall return without delay. An open() for writing-only shall return an error if no process currently has the file open for reading. If O_NONBLOCK is clear, an open() for reading-only shall block the calling thread until a thread opens the file for writing. An open() for writing-only shall block the calling thread until a thread opens the file for reading. When opening a block special or character special file that supports non-blocking opens: If O_NONBLOCK is set, the open() function shall return without blocking for the device to be ready or available. Subsequent behavior of the device is device-specific. If O_NONBLOCK is clear, the open() function shall block the calling thread until the device is ready or available before returning. Otherwise, the behavior of O_NONBLOCK is unspecified. Basically, syscall should not block waiting for some data to be read (or written). The ioctl definition defines [EAGAIN] error code, if, for any reason, an ioctl would block. Btw, the vtunerc doesn't handle O_NONBLOCK flag. For each DVB ioctl, for example read_snr[1], it calls wait_event_interruptible()[2], even if the application opens it with O_NONBLOCK flag. So, it is likely that non-blocking-mode applications will break. [1] http://code.google.com/p/vtuner/source/browse/vtunerc_proxyfe.c?repo=linux-driver#75 [2] http://code.google.com/p/vtuner/source/browse/vtunerc_ctrldev.c?repo=linux-driver#420 Mauro, if the network is broken, any application using the network will break. No specially designed protocol will fix that. A high delay network (even a congested one) is not broken, if it can still provide the throughput required by the application, and a latency/QoS that would fit. If you want to enforce strict maximum latencies, you can do that in the userspace daemon using the vtunerc interface. It has all imaginable possibilities to control data flow over the network and to return errors to vtunerc. Yes, you can do anything you want at the userspace daemon, but the non-userspace daemon aware applications will know nothing about it, and this is the flaw on this design: Applications can't negotiate what network parameters are ok or not for its usecase. For a DVB API application it doesn't matter whether a tuning request fails with EIO because a USB device has been removed, a PCI device encountered an I2C error or because the vtuner userspace daemon returned an error. When you go to network, there are several errors that are transitory. For example, a dropped link may cause the routing protocol (RIP, BGP or whatever) to re-direct several routes (or, on a LAN, a spanning-tree re-negotiation), causing a temporary failure to deliver a few packets. All network-based application are written to consider temporary failures. This is fundamentally different than an application designed to talk directly with the hardware, where an error is generally fatal. [1] Btw, if some DVB ioctl currently waits in O_NONBLOCK, this is a POSIX violation that needs to be fixed. To the best of my knowledge, this doesn't happen. I think we all realized some days ago that the code is not going to be merged upstream anytime in the foreseeable future. You can stop using such pointless arguments. Agreed. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 06.12.2011 14:22, Mauro Carvalho Chehab wrote: > On 05-12-2011 22:07, HoP wrote: >>> I doubt that scan or w_scan would support it. Even if it supports, that >>> would mean that, >>> for each ioctl that would be sent to the remote server, the error >>> code would >>> take 480 ms >>> to return. Try to calculate how many time w_scan would work with >>> that. The >>> calculus is easy: >>> see how many ioctl's are called by each frequency and multiply by the >>> number >>> of frequencies >>> that it would be seek. You should then add the delay introduced over >>> streaming the data >>> from the demux, using the same calculus. This is the additional time >>> over a >>> local w_scan. >>> >>> A grouch calculus with scandvb: to tune into a single DVB-C >>> frequency, it >>> used 45 ioctls. >>> Each taking 480 ms round trip would mean an extra delay of 21.6 seconds. >>> There are 155 >>> possible frequencies here. So, imagining that scan could deal with 21.6 >>> seconds of delay >>> for each channel (with it doesn't), the extra delay added by it is 1 >>> hour >>> (45 * 0.48 * 155). >>> >>> On the other hand, a solution like the one described by Florian would >>> introduce a delay of >>> 480 ms for the entire scan to happen, as only one data packet would be >>> needed to send a >>> scan request, and one one stream of packets traveling at 10GB/s would >>> bring >>> the answer >>> back. >> >> Andreas was excited by your imaginations and calculations, but not me. >> Now you again manifested you are not treating me as partner for >> discussion. >> Otherwise you should try to understand how-that-ugly-hack works. >> But you surelly didn't try to do it at all. >> >> How do you find those 45 ioctls for DVB-C tune? > > With strace. See how many ioctl's are called for each tune. Ok, perhaps > scandvb > is badly written, but if your idea is to support 100% of the > applications, you > should be prepared for badly written applications. > > $strace -e ioctl scandvb dvbc-teste > scanning dvbc-teste > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > ioctl(3, FE_GET_INFO, 0x60a640) = 0 > initial transponder 57300 5217000 0 5 tune to: 57300:INVERSION_AUTO:5217000:FEC_NONE:QAM_256 > ioctl(3, FE_SET_FRONTEND, 0x7fff5f7f2cd0) = 0 > ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0 > ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0 > ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0 > ioctl(4, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0 > ioctl(5, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0 > ioctl(6, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0 > ioctl(7, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(8, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(9, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(10, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(11, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(12, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(13, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(14, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(15, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(16, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(17, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(18, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(19, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(20, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(21, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(22, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(23, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(24, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 > ioctl(4, DMX_STOP, 0x1) = 0 > ioctl(15, DMX_STOP, 0x1)= 0 > ioctl(11, DMX_STOP, 0x1)= 0 > ioctl(22, DMX_STOP, 0x1)= 0 > ioctl(17, DMX_STOP, 0x1)= 0 > ioctl(16, DMX_STOP, 0x1)= 0 You don't need to wait for write-only operations. Basically all demux ioctls are write-only. Since vtunerc is using dvb-core's software demux *locally*, errors for invalid arguments etc. will be returned as usual. What's left is one call to FE_SET_FRONTEND for each frequency to tune to, and one FE_READ_STATUS for each time the lock status is queried. Note that one may use FE_GET_EVENT instead of FE_READ_STATUS to get notified of status changes asynchronously if desired. Btw.: FE_SET_FRONTEND doesn't block either, because the driver callback is called from a dvb_frontend's *local* kernel thread. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 06.12.2011 14:10, Mauro Carvalho Chehab wrote: > On 06-12-2011 10:01, Andreas Oberritter wrote: >> On 06.12.2011 12:18, Mark Brown wrote: >>> On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote: On 05.12.2011 21:55, Alan Cox wrote: > The USB case is quite different because your latency is very tightly > bounded, your dead device state is rigidly defined, and your loss of > device is accurately and immediately signalled. >>> > Quite different. >>> How can usbip work if networking and usb are so different and what's so different between vtunerc and usbip, that made it possible to put usbip into drivers/staging? >>> >>> USB-IP is a hack that will only work well on a tightly bounded set of >>> networks - if you run it over a lightly loaded local network it can >>> work adequately. This starts to break down as you vary the network >>> configuration. >> >> I see. So it has problems that vtunerc doesn't have. > > The vtunerc has the same issues. High latency (due to high loads, high > latency links or whatever) affects it badly, and may cause application > breakages if if the device is opened are using O_NONBLOCK mode [1]. O_NONBLOCK doesn't mean that an ioctl must consume zero time. It just means that it should return instead of waiting for (more) data to become available or writeable. Mauro, if the network is broken, any application using the network will break. No specially designed protocol will fix that. If you want to enforce strict maximum latencies, you can do that in the userspace daemon using the vtunerc interface. It has all imaginable possibilities to control data flow over the network and to return errors to vtunerc. For a DVB API application it doesn't matter whether a tuning request fails with EIO because a USB device has been removed, a PCI device encountered an I2C error or because the vtuner userspace daemon returned an error. > [1] Btw, if some DVB ioctl currently waits in O_NONBLOCK, this is a POSIX > violation that needs to be fixed. To the best of my knowledge, this doesn't happen. I think we all realized some days ago that the code is not going to be merged upstream anytime in the foreseeable future. You can stop using such pointless arguments. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 05-12-2011 22:07, HoP wrote: I doubt that scan or w_scan would support it. Even if it supports, that would mean that, for each ioctl that would be sent to the remote server, the error code would take 480 ms to return. Try to calculate how many time w_scan would work with that. The calculus is easy: see how many ioctl's are called by each frequency and multiply by the number of frequencies that it would be seek. You should then add the delay introduced over streaming the data from the demux, using the same calculus. This is the additional time over a local w_scan. A grouch calculus with scandvb: to tune into a single DVB-C frequency, it used 45 ioctls. Each taking 480 ms round trip would mean an extra delay of 21.6 seconds. There are 155 possible frequencies here. So, imagining that scan could deal with 21.6 seconds of delay for each channel (with it doesn't), the extra delay added by it is 1 hour (45 * 0.48 * 155). On the other hand, a solution like the one described by Florian would introduce a delay of 480 ms for the entire scan to happen, as only one data packet would be needed to send a scan request, and one one stream of packets traveling at 10GB/s would bring the answer back. Andreas was excited by your imaginations and calculations, but not me. Now you again manifested you are not treating me as partner for discussion. Otherwise you should try to understand how-that-ugly-hack works. But you surelly didn't try to do it at all. How do you find those 45 ioctls for DVB-C tune? With strace. See how many ioctl's are called for each tune. Ok, perhaps scandvb is badly written, but if your idea is to support 100% of the applications, you should be prepared for badly written applications. $strace -e ioctl scandvb dvbc-teste scanning dvbc-teste using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' ioctl(3, FE_GET_INFO, 0x60a640) = 0 initial transponder 57300 5217000 0 5 tune to: 57300:INVERSION_AUTO:5217000:FEC_NONE:QAM_256 ioctl(3, FE_SET_FRONTEND, 0x7fff5f7f2cd0) = 0 ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0 ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0 ioctl(3, FE_READ_STATUS, 0x7fff5f7f2cfc) = 0 ioctl(4, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0 ioctl(5, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0 ioctl(6, DMX_SET_FILTER, 0x7fff5f7f1ad0) = 0 ioctl(7, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(8, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(9, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(10, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(11, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(12, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(13, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(14, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(15, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(16, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(17, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(18, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(19, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(20, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(21, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(22, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(23, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(24, DMX_SET_FILTER, 0x7fff5f7f1910) = 0 ioctl(4, DMX_STOP, 0x1) = 0 ioctl(15, DMX_STOP, 0x1)= 0 ioctl(11, DMX_STOP, 0x1)= 0 ioctl(22, DMX_STOP, 0x1)= 0 ioctl(17, DMX_STOP, 0x1)= 0 ioctl(16, DMX_STOP, 0x1)= 0 0x 0x0004: pmt_pid 0x0108 (null) -- SBT (running) 0x 0x0005: pmt_pid 0x0250 (null) -- Globo (running) 0x 0x0007: pmt_pid 0x0128 (null) -- Record (running) 0x 0x000d: pmt_pid 0x0118 (null) -- Band (running) 0x 0x002e: pmt_pid 0x0148 (null) -- Cartoon Network (running, scrambled) 0x 0x0030: pmt_pid 0x0158 (null) -- TNT (running, scrambled) 0x 0x0039: pmt_pid 0x0168 (null) -- Boomerang (running, scrambled) 0x 0x0090: pmt_pid 0x0178 (null) -- DW-TV (running, scrambled) 0x 0x0098: pmt_pid 0x0188 (null) -- BBC World News (running, scrambled) 0x 0x00cb: pmt_pid 0x01a8 (null) -- NET Games (running) 0x 0x012c: pmt_pid 0x0198 (null) -- NET M�sica (running, scrambled) 0x 0x0133: pmt_pid 0x0022 (null) -- Pagode (running) 0x 0x0135: pmt_pid 0x0020 (null) -- Ax� (running) 0x 0x0146: pmt_pid 0x0023 (null) -- Festa (running) 0x 0x0156: pmt_pid 0x0024 (null) -- Trilhas Sonoras (running) 0x 0x015b: pmt_pid 0x0021 (null) -- Radio Multishow (running) 0x 0x0320: pmt_pid 0x02c4 (null) -- 01070136 (running) 0x 0x0321: pmt_pid 0x02c5 (null) -- 01070236 (running) ioctl(5, DMX_STOP, 0x1) = 0 ioctl(24, DMX_STOP, 0x1)= 0 ioctl(23, DMX_STOP, 0x1)= 0 ioctl(7, DMX_STOP, 0x1) = 0 ioctl(19, DMX_STOP, 0x1)= 0 ioctl(18, DMX_STOP, 0x1)= 0 ioctl(21, DMX_STOP, 0x1)= 0 ioctl(12, DMX_STOP, 0x1)= 0 ioctl(13, DMX_STOP, 0x1)= 0 ioctl(20, DMX_STOP, 0x1)= 0 ioctl(10, DMX_STOP, 0x1)
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 06-12-2011 10:01, Andreas Oberritter wrote: On 06.12.2011 12:18, Mark Brown wrote: On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote: On 05.12.2011 21:55, Alan Cox wrote: The USB case is quite different because your latency is very tightly bounded, your dead device state is rigidly defined, and your loss of device is accurately and immediately signalled. Quite different. How can usbip work if networking and usb are so different and what's so different between vtunerc and usbip, that made it possible to put usbip into drivers/staging? USB-IP is a hack that will only work well on a tightly bounded set of networks - if you run it over a lightly loaded local network it can work adequately. This starts to break down as you vary the network configuration. I see. So it has problems that vtunerc doesn't have. The vtunerc has the same issues. High latency (due to high loads, high latency links or whatever) affects it badly, and may cause application breakages if if the device is opened are using O_NONBLOCK mode [1]. Regards, Mauro. [1] Btw, if some DVB ioctl currently waits in O_NONBLOCK, this is a POSIX violation that needs to be fixed. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 06.12.2011 12:21, Mark Brown wrote: > On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote: >> On 05.12.2011 18:39, Mauro Carvalho Chehab wrote: > >>> When you put someone via the network, issues like latency, package >>> drops, IP >>> congestion, QoS issues, cryptography, tunneling, etc should be taken >>> into account >>> by the application, in order to properly address the network issues. > >> Are you serious? Lower networking layers should be transparent to the >> upper layers. You don't implement VPN or say TCP in all of your >> applications, do you? These are just some more made-up arguments which >> don't have anything to do with the use cases I explained earlier. > > For real time applications it does make a big difference - decisions > taken at the application level can greatly impact end application > performance. For example with VoIP on a LAN you can get great audio > quality by using very little compression at the expense of high > bandwidth and you can probably use a very small jitter buffer. Try > doing that over a longer distance or more congested network which drops > packets and it becomes useful to use a more commpressed encoding for > your data which may have better features for handling packet loss, or to > increase your jitter buffer to cope with the less reliable transmit > times. Can you please explain how this relates to the topic we're discussing? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 06.12.2011 12:18, Mark Brown wrote: > On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote: >> On 05.12.2011 21:55, Alan Cox wrote: >>> The USB case is quite different because your latency is very tightly >>> bounded, your dead device state is rigidly defined, and your loss of >>> device is accurately and immediately signalled. > >>> Quite different. > >> How can usbip work if networking and usb are so different and what's so >> different between vtunerc and usbip, that made it possible to put usbip >> into drivers/staging? > > USB-IP is a hack that will only work well on a tightly bounded set of > networks - if you run it over a lightly loaded local network it can > work adequately. This starts to break down as you vary the network > configuration. I see. So it has problems that vtunerc doesn't have. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote: > On 05.12.2011 18:39, Mauro Carvalho Chehab wrote: > > When you put someone via the network, issues like latency, package > > drops, IP > > congestion, QoS issues, cryptography, tunneling, etc should be taken > > into account > > by the application, in order to properly address the network issues. > Are you serious? Lower networking layers should be transparent to the > upper layers. You don't implement VPN or say TCP in all of your > applications, do you? These are just some more made-up arguments which > don't have anything to do with the use cases I explained earlier. For real time applications it does make a big difference - decisions taken at the application level can greatly impact end application performance. For example with VoIP on a LAN you can get great audio quality by using very little compression at the expense of high bandwidth and you can probably use a very small jitter buffer. Try doing that over a longer distance or more congested network which drops packets and it becomes useful to use a more commpressed encoding for your data which may have better features for handling packet loss, or to increase your jitter buffer to cope with the less reliable transmit times. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote: > On 05.12.2011 21:55, Alan Cox wrote: > > The USB case is quite different because your latency is very tightly > > bounded, your dead device state is rigidly defined, and your loss of > > device is accurately and immediately signalled. > > Quite different. > How can usbip work if networking and usb are so different and what's so > different between vtunerc and usbip, that made it possible to put usbip > into drivers/staging? USB-IP is a hack that will only work well on a tightly bounded set of networks - if you run it over a lightly loaded local network it can work adequately. This starts to break down as you vary the network configuration. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi Michael 2011/12/5 Michael Krufky : > On Mon, Dec 5, 2011 at 9:28 AM, HoP wrote: >> Hi >> >> 2011/12/5 Florian Fainelli : >>> Hello, >>> >>> >>> On 12/03/11 01:37, HoP wrote: Hi Alan. 2011/12/3 Alan Cox: > > On Thu, 1 Dec 2011 15:58:41 +0100 > HoP wrote: > >> Hi, >> >> let me ask you some details of your interesting idea (how to >> achieve the same functionality as with vtunerc driver): >> >> [...] >> >>> The driver, as proposed, is not really a driver, as it doesn't support >>> any >>> hardware. The kernel driver would be used to just copy data from one >>> userspace >> >> >> Please stop learning me what can be called driver and what nope. >> Your definition is nonsense and I don't want to follow you on it. > > > You can stick your fingers in your ears and shout all you like but given > Mauro is the maintainer I'd suggest you work with him rather than making > it painful. One of the failures we routinely exclude code from the kernel > for is best described as "user interface of contributor" You may be not read all my mails but I really tried to be very positive in them. I wanted to focus on my Subject, but Mauro has, sometimes, the demand to focus on insignificant things (like if the code is driver or not). At least it is my feeling from all those disscussions with him. > > It's a loopback that adds a performance hit. The right way to do this is > in userspace with the userspace infrastructure. At that point you can > handle all the corner cases properly, integrate things like service > discovery into your model and so on - stuff you'll never get to work that > well with kernel loopback hackery. > >> Can you show me, how then can be reused most important part >> of dvb-core subsystem like tuning and demuxing? Or do you want me >> to invent wheels and to recode everything in the library? Of course > > > You could certainly build a library from the same code. That might well > be a good thing for all kinds of 'soft' DV applications. At that point > the discussion to have is the best way to make that code sharable between > a userspace library and the kernel and buildable for both. > >> I can be wrong, I'm no big kernel hacker. So please show me the >> way for it. BTW, even if you can find the way, then data copying >> from userspace to the kernel and back is also necessery. I really >> don't see any advantage of you solution. > > > In a properly built media subsystem you shouldn't need any copies beyond > those that naturally occur as part of a processing pass and are therefore > free. I may describe project goal, in few sentences: We have small box, running embedded linux with 2 satellite tuners on input and ethernet. Nothing more. We have designed the box for live sat TV/Radio reception, distributing them down to the network. One of the mode of working is "vtuner", what allows reuse those tuners remotely on linux desktop. The kernel part is very simple code exposing kernel's dvb-core to the userspace. Userspace client/server tools do all resource discovery and connection management. It works nicely and guys with vdr who is using it are rather satisfied with it. So, the main goal of vtuner code is to fully virtualize remote DVB adapter. To any linux dvb api compatible applications and tools. The vtuner kernel code seems to be the simplest and straightforward way to achieve it. >>> >>> >>> The company I work for also has something like this. We can attach a DVB >>> tuner to either the Gateway or the STB we provide and use it indifferently , >>> except that we have the following architecture: >>> >>> - a DVB daemon controlling the physical DVB tuner and exposing methods for >>> tuning/scanning/zapping >>> - a web server and web services for accessing the DVB daemon methods >>> - a RTSP streamer with associated methods for controlling streaming >>> >>> The software running on both devices is the same (one compiled for ARM, the >>> other for x86). >>> >>> I do not see any problem with this solution, people wanting to get the >>> stream can still get the RTSP stream directly joining the multicast group, >>> which is fortunately OS agnostic at the same time. >> >> Nice. Are your solution open-sourced? If so, can you give me URL? >> I still think the code is very similar to NBD (Network block device) what sits in the kernel and is using silently. I guess NBD also do data copying from/to user space. Is there something what I overlooked? Can you show me the way (hint please) I can initiate TCP connection from within kernel space? If I can do it, then the big disadvantage of data passing to and from kernel can be remove
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
> I doubt that scan or w_scan would support it. Even if it supports, that > would mean that, > for each ioctl that would be sent to the remote server, the error code would > take 480 ms > to return. Try to calculate how many time w_scan would work with that. The > calculus is easy: > see how many ioctl's are called by each frequency and multiply by the number > of frequencies > that it would be seek. You should then add the delay introduced over > streaming the data > from the demux, using the same calculus. This is the additional time over a > local w_scan. > > A grouch calculus with scandvb: to tune into a single DVB-C frequency, it > used 45 ioctls. > Each taking 480 ms round trip would mean an extra delay of 21.6 seconds. > There are 155 > possible frequencies here. So, imagining that scan could deal with 21.6 > seconds of delay > for each channel (with it doesn't), the extra delay added by it is 1 hour > (45 * 0.48 * 155). > > On the other hand, a solution like the one described by Florian would > introduce a delay of > 480 ms for the entire scan to happen, as only one data packet would be > needed to send a > scan request, and one one stream of packets traveling at 10GB/s would bring > the answer > back. Andreas was excited by your imaginations and calculations, but not me. Now you again manifested you are not treating me as partner for discussion. Otherwise you should try to understand how-that-ugly-hack works. But you surelly didn't try to do it at all. How do you find those 45 ioctls for DVB-C tune? I still see only one ioctl FE_SET_FRONTEND or v5+ variant FE_SET_PROPERTY. Sorry, but, for example, szap tunes very close to local variant: # time szap -c channels.conf -x Ocko reading channels from file 'channels.conf' zapping to 15 'ocko': sat 0, frequency = 12168 MHz V, symbolrate 2750, vpid = 0x00a0, apid = 0x0050 sid = 0x1451 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 1f | signal d410 | snr d380 | ber | unc | FE_HAS_LOCK 0.00user 0.00system 0:01.33elapsed 0%CPU (0avgtext+0avgdata 2000maxresident)k 0inputs+0outputs (0major+171minor)pagefaults 0swaps Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
> How can usbip work if networking and usb are so different and what's so > different between vtunerc and usbip, that made it possible to put usbip > into drivers/staging? Where usbip seems to have remained for a long time without actually being made useful or correct enough to progress. Meanwhile most remote USB device access is at a higher level and works beautifully (eg remote USB printing). Case proven I think rather than the reverse Alan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 05.12.2011 21:55, Alan Cox wrote: > The USB case is quite different because your latency is very tightly > bounded, your dead device state is rigidly defined, and your loss of > device is accurately and immediately signalled. > > Quite different. How can usbip work if networking and usb are so different and what's so different between vtunerc and usbip, that made it possible to put usbip into drivers/staging? Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
The USB case is quite different because your latency is very tightly bounded, your dead device state is rigidly defined, and your loss of device is accurately and immediately signalled. Quite different. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 05.12.2011 18:39, Mauro Carvalho Chehab wrote: > On 05-12-2011 12:28, HoP wrote: > >>> And here is a new hack. >> >> I'm really tired from all those "hack, crap, pigback ..." wordings. >> >> What exactly vtuner aproach does so hackish (other then exposing >> DVB internals, what is every time made if virtualization support is >> developing)? >> >> 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. >> >> I can understand that some developers don't like to get dvb-core opened, >> I don't agree with them, but I don't really need to fight with them. >> Its theirs opinion. >> But even I try to see what is so hackish in vtuner implementation, I >> don't catch >> anything. Simplicity? I thought that simplicity is a big advanatge >> (simple code, >> easy to analyze). What else? > > You solution is called a hack becaus it is used to fool applications to > think that a > remote device is actually a local device. Being it at kernelspace or at > userspace > (with CUSE, LD_PRELOADER of whatever other solution) doesn't change this > fact. > > As applications know nothing about it, they'll still use timeouts and > other coding logic > that fits well for a locally-accessible device, but that won't fit well > for a remote > connection. See (*) below. > You should remind that, by remote, this could mean a > cross-ethernet > connection dedicated to it or a 20,000 Km far away machine, using > satellite links. > > When you put someone via the network, issues like latency, package > drops, IP > congestion, QoS issues, cryptography, tunneling, etc should be taken > into account > by the application, in order to properly address the network issues. Are you serious? Lower networking layers should be transparent to the upper layers. You don't implement VPN or say TCP in all of your applications, do you? These are just some more made-up arguments which don't have anything to do with the use cases I explained earlier. > Those network-specific issues affect applications badly, if they're not > prepared to > handle with that, and if the used protocol is not adequate. It is not > for a reason that > there are lots of different protocols designed for streaming broadcast, > and a lot of > money is spent on improving it. (*) DVB isn't local either. It's using broadcast media after all. It's designed to cope with packet loss and includes relative decoding and presentation time stamps in its media payloads. Although DVB specifies some minimal repetition rates for repeatedly sent data, real life applications need to handle much lower repetition rates anyway (i.e. higher timeouts), in order to cope with individual settings of broadcasters trying to save some bandwidth in their multiplexes. Real life applications also need to handle high timeouts due to possible packet loss, especially in satellite and terrestrial networks. However, the TS transport between the client and server components may very well use one of the protocols you're referring to, yes. > Can you warrant that 100% of DVB applications you claimed to support > will work well > if a high latency network with a few satellite links is used, even if it > has enough > bandwidth)? If you think so, a typical satellite latency is 240 ms per > link, in > the best case [1]. A round trip takes twice this time. > > So, a 10 GB connection with just one satellite link would mean about 480 > ms of round trip. Again, are you serious? Virtually all users I expect will use their local network and you're using a satellite link as an example to explain why you think it's going to suck for everybody? I don't know anybody who's voluntarily using a satellite link for his internet connection. Roundtrip time in my LAN is about 0.25 ms, which is 1/1920th of your "typical" example. I also don't understand how your 10 GB (sic!) of bandwidth come into play, if only few MBit/s are required to transfer a DVB video service (or few KBit/s for audio or data). You're suggesting high bandwidth usage to uninformed readers, where maybe only few bytes are to be transferred. You're suggesting that this project is still a theory, but it's already there and it's already in use by many people, who are happy with it. So latency can't be such a big problem as you're trying to point out. Regarding increased latency for ioctls: The Linux DVB API doesn't specifiy any time frames within which ioctls must return. Most ioctls are known to block, the few others handle non-blocking mode. Adding some ms delay for the network transfer really is no problem at all. Regarding the asynchronous nature of networking: USB transfers are asynchronous too, but USB tuners work well using in-kernel drivers. The usbip even combines both asynchronous worlds. Oh wait, usbip already resides in staging. How come? [stripped off-topic latency calculations for satellite IP networks] > On the other hand, a s
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 05-12-2011 12:28, HoP wrote: And here is a new hack. I'm really tired from all those "hack, crap, pigback ..." wordings. What exactly vtuner aproach does so hackish (other then exposing DVB internals, what is every time made if virtualization support is developing)? 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. I can understand that some developers don't like to get dvb-core opened, I don't agree with them, but I don't really need to fight with them. Its theirs opinion. But even I try to see what is so hackish in vtuner implementation, I don't catch anything. Simplicity? I thought that simplicity is a big advanatge (simple code, easy to analyze). What else? You solution is called a hack becaus it is used to fool applications to think that a remote device is actually a local device. Being it at kernelspace or at userspace (with CUSE, LD_PRELOADER of whatever other solution) doesn't change this fact. As applications know nothing about it, they'll still use timeouts and other coding logic that fits well for a locally-accessible device, but that won't fit well for a remote connection. You should remind that, by remote, this could mean a cross-ethernet connection dedicated to it or a 20,000 Km far away machine, using satellite links. When you put someone via the network, issues like latency, package drops, IP congestion, QoS issues, cryptography, tunneling, etc should be taken into account by the application, in order to properly address the network issues. Those network-specific issues affect applications badly, if they're not prepared to handle with that, and if the used protocol is not adequate. It is not for a reason that there are lots of different protocols designed for streaming broadcast, and a lot of money is spent on improving it. Can you warrant that 100% of DVB applications you claimed to support will work well if a high latency network with a few satellite links is used, even if it has enough bandwidth)? If you think so, a typical satellite latency is 240 ms per link, in the best case [1]. A round trip takes twice this time. So, a 10 GB connection with just one satellite link would mean about 480 ms of round trip. I doubt that scan or w_scan would support it. Even if it supports, that would mean that, for each ioctl that would be sent to the remote server, the error code would take 480 ms to return. Try to calculate how many time w_scan would work with that. The calculus is easy: see how many ioctl's are called by each frequency and multiply by the number of frequencies that it would be seek. You should then add the delay introduced over streaming the data from the demux, using the same calculus. This is the additional time over a local w_scan. A grouch calculus with scandvb: to tune into a single DVB-C frequency, it used 45 ioctls. Each taking 480 ms round trip would mean an extra delay of 21.6 seconds. There are 155 possible frequencies here. So, imagining that scan could deal with 21.6 seconds of delay for each channel (with it doesn't), the extra delay added by it is 1 hour (45 * 0.48 * 155). On the other hand, a solution like the one described by Florian would introduce a delay of 480 ms for the entire scan to happen, as only one data packet would be needed to send a scan request, and one one stream of packets traveling at 10GB/s would bring the answer back. Note: even links without satellite may suffer high delays. The delay introduced by an USB modem for a 3G data connection is probably high enough to cause applications like w_scan to fail. Your approach for sure works on your network scenario, but it is a very sensitive to network issues, as applications have no idea about the network connection, and would do the wrong thing when a network error occurs. What I'm saying you is that the proper way to address it is to create a library that would abstract the DVB operations (scan, tuning, filtering, ...) into a way that it could be called either locally or remotely. Then, work with userspace developers to support it. As I said before, all network-based audio/video stream solutions work this way. They don't try to hide themselves by emulating a local device, as this don't work in a general case. If you succeed to create a clean, properly written DVB library that would work fine for remote devices, I'm sure you will be able to convince most application maintainers to use it. Regards, Mauro [1] http://www.satsig.net/latency.htm Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Mon, Dec 5, 2011 at 9:28 AM, HoP wrote: > Hi > > 2011/12/5 Florian Fainelli : >> Hello, >> >> >> On 12/03/11 01:37, HoP wrote: >>> >>> Hi Alan. >>> >>> 2011/12/3 Alan Cox: On Thu, 1 Dec 2011 15:58:41 +0100 HoP wrote: > Hi, > > let me ask you some details of your interesting idea (how to > achieve the same functionality as with vtunerc driver): > > [...] > >> The driver, as proposed, is not really a driver, as it doesn't support >> any >> hardware. The kernel driver would be used to just copy data from one >> userspace > > > Please stop learning me what can be called driver and what nope. > Your definition is nonsense and I don't want to follow you on it. You can stick your fingers in your ears and shout all you like but given Mauro is the maintainer I'd suggest you work with him rather than making it painful. One of the failures we routinely exclude code from the kernel for is best described as "user interface of contributor" >>> >>> >>> You may be not read all my mails but I really tried to be very positive in >>> them. >>> I wanted to focus on my Subject, but Mauro has, sometimes, the demand >>> to focus on insignificant things (like if the code is driver or not). At >>> least >>> it is my feeling from all those disscussions with him. >>> It's a loopback that adds a performance hit. The right way to do this is in userspace with the userspace infrastructure. At that point you can handle all the corner cases properly, integrate things like service discovery into your model and so on - stuff you'll never get to work that well with kernel loopback hackery. > Can you show me, how then can be reused most important part > of dvb-core subsystem like tuning and demuxing? Or do you want me > to invent wheels and to recode everything in the library? Of course You could certainly build a library from the same code. That might well be a good thing for all kinds of 'soft' DV applications. At that point the discussion to have is the best way to make that code sharable between a userspace library and the kernel and buildable for both. > I can be wrong, I'm no big kernel hacker. So please show me the > way for it. BTW, even if you can find the way, then data copying > from userspace to the kernel and back is also necessery. I really > don't see any advantage of you solution. In a properly built media subsystem you shouldn't need any copies beyond those that naturally occur as part of a processing pass and are therefore free. >>> >>> >>> I may describe project goal, in few sentences: We have small box, running >>> embedded linux with 2 satellite tuners on input and ethernet. Nothing >>> more. >>> We have designed the box for live sat TV/Radio reception, distributing >>> them >>> down to the network. One of the mode of working is "vtuner", what allows >>> reuse those tuners remotely on linux desktop. The kernel part is very >>> simple >>> code exposing kernel's dvb-core to the userspace. Userspace client/server >>> tools do all resource discovery and connection management. It works >>> nicely and guys with vdr who is using it are rather satisfied with it. >>> So, the main >>> goal of vtuner code is to fully virtualize remote DVB adapter. To any >>> linux dvb api >>> compatible applications and tools. The vtuner kernel code seems to be >>> the simplest and straightforward way to achieve it. >> >> >> The company I work for also has something like this. We can attach a DVB >> tuner to either the Gateway or the STB we provide and use it indifferently , >> except that we have the following architecture: >> >> - a DVB daemon controlling the physical DVB tuner and exposing methods for >> tuning/scanning/zapping >> - a web server and web services for accessing the DVB daemon methods >> - a RTSP streamer with associated methods for controlling streaming >> >> The software running on both devices is the same (one compiled for ARM, the >> other for x86). >> >> I do not see any problem with this solution, people wanting to get the >> stream can still get the RTSP stream directly joining the multicast group, >> which is fortunately OS agnostic at the same time. > > Nice. Are your solution open-sourced? If so, can you give me URL? > >>> I still think the code is very similar to NBD (Network block device) what >>> sits >>> in the kernel and is using silently. I guess NBD also do data copying >>> from/to user space. Is there something what I overlooked? >>> >>> Can you show me the way (hint please) I can initiate TCP connection >>> from within kernel space? If I can do it, then the big disadvantage >>> of data passing to and from kernel can be removed. >> >> >> Don't do this in kernel-space (remember the mechanism/policy split). > > Yes, that can be the issue, I understand that. > > You know - I'm a bit c
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi 2011/12/5 Florian Fainelli : > Hello, > > > On 12/03/11 01:37, HoP wrote: >> >> Hi Alan. >> >> 2011/12/3 Alan Cox: >>> >>> On Thu, 1 Dec 2011 15:58:41 +0100 >>> HoP wrote: >>> Hi, let me ask you some details of your interesting idea (how to achieve the same functionality as with vtunerc driver): [...] > The driver, as proposed, is not really a driver, as it doesn't support > any > hardware. The kernel driver would be used to just copy data from one > userspace Please stop learning me what can be called driver and what nope. Your definition is nonsense and I don't want to follow you on it. >>> >>> >>> You can stick your fingers in your ears and shout all you like but given >>> Mauro is the maintainer I'd suggest you work with him rather than making >>> it painful. One of the failures we routinely exclude code from the kernel >>> for is best described as "user interface of contributor" >> >> >> You may be not read all my mails but I really tried to be very positive in >> them. >> I wanted to focus on my Subject, but Mauro has, sometimes, the demand >> to focus on insignificant things (like if the code is driver or not). At >> least >> it is my feeling from all those disscussions with him. >> >>> >>> It's a loopback that adds a performance hit. The right way to do this is >>> in userspace with the userspace infrastructure. At that point you can >>> handle all the corner cases properly, integrate things like service >>> discovery into your model and so on - stuff you'll never get to work that >>> well with kernel loopback hackery. >>> Can you show me, how then can be reused most important part of dvb-core subsystem like tuning and demuxing? Or do you want me to invent wheels and to recode everything in the library? Of course >>> >>> >>> You could certainly build a library from the same code. That might well >>> be a good thing for all kinds of 'soft' DV applications. At that point >>> the discussion to have is the best way to make that code sharable between >>> a userspace library and the kernel and buildable for both. >>> I can be wrong, I'm no big kernel hacker. So please show me the way for it. BTW, even if you can find the way, then data copying from userspace to the kernel and back is also necessery. I really don't see any advantage of you solution. >>> >>> >>> In a properly built media subsystem you shouldn't need any copies beyond >>> those that naturally occur as part of a processing pass and are therefore >>> free. >> >> >> I may describe project goal, in few sentences: We have small box, running >> embedded linux with 2 satellite tuners on input and ethernet. Nothing >> more. >> We have designed the box for live sat TV/Radio reception, distributing >> them >> down to the network. One of the mode of working is "vtuner", what allows >> reuse those tuners remotely on linux desktop. The kernel part is very >> simple >> code exposing kernel's dvb-core to the userspace. Userspace client/server >> tools do all resource discovery and connection management. It works >> nicely and guys with vdr who is using it are rather satisfied with it. >> So, the main >> goal of vtuner code is to fully virtualize remote DVB adapter. To any >> linux dvb api >> compatible applications and tools. The vtuner kernel code seems to be >> the simplest and straightforward way to achieve it. > > > The company I work for also has something like this. We can attach a DVB > tuner to either the Gateway or the STB we provide and use it indifferently , > except that we have the following architecture: > > - a DVB daemon controlling the physical DVB tuner and exposing methods for > tuning/scanning/zapping > - a web server and web services for accessing the DVB daemon methods > - a RTSP streamer with associated methods for controlling streaming > > The software running on both devices is the same (one compiled for ARM, the > other for x86). > > I do not see any problem with this solution, people wanting to get the > stream can still get the RTSP stream directly joining the multicast group, > which is fortunately OS agnostic at the same time. Nice. Are your solution open-sourced? If so, can you give me URL? >> I still think the code is very similar to NBD (Network block device) what >> sits >> in the kernel and is using silently. I guess NBD also do data copying >> from/to user space. Is there something what I overlooked? >> >> Can you show me the way (hint please) I can initiate TCP connection >> from within kernel space? If I can do it, then the big disadvantage >> of data passing to and from kernel can be removed. > > > Don't do this in kernel-space (remember the mechanism/policy split). Yes, that can be the issue, I understand that. 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 fro
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hello, On 12/03/11 01:37, HoP wrote: Hi Alan. 2011/12/3 Alan Cox: On Thu, 1 Dec 2011 15:58:41 +0100 HoP wrote: Hi, let me ask you some details of your interesting idea (how to achieve the same functionality as with vtunerc driver): [...] The driver, as proposed, is not really a driver, as it doesn't support any hardware. The kernel driver would be used to just copy data from one userspace Please stop learning me what can be called driver and what nope. Your definition is nonsense and I don't want to follow you on it. You can stick your fingers in your ears and shout all you like but given Mauro is the maintainer I'd suggest you work with him rather than making it painful. One of the failures we routinely exclude code from the kernel for is best described as "user interface of contributor" You may be not read all my mails but I really tried to be very positive in them. I wanted to focus on my Subject, but Mauro has, sometimes, the demand to focus on insignificant things (like if the code is driver or not). At least it is my feeling from all those disscussions with him. It's a loopback that adds a performance hit. The right way to do this is in userspace with the userspace infrastructure. At that point you can handle all the corner cases properly, integrate things like service discovery into your model and so on - stuff you'll never get to work that well with kernel loopback hackery. Can you show me, how then can be reused most important part of dvb-core subsystem like tuning and demuxing? Or do you want me to invent wheels and to recode everything in the library? Of course You could certainly build a library from the same code. That might well be a good thing for all kinds of 'soft' DV applications. At that point the discussion to have is the best way to make that code sharable between a userspace library and the kernel and buildable for both. I can be wrong, I'm no big kernel hacker. So please show me the way for it. BTW, even if you can find the way, then data copying from userspace to the kernel and back is also necessery. I really don't see any advantage of you solution. In a properly built media subsystem you shouldn't need any copies beyond those that naturally occur as part of a processing pass and are therefore free. I may describe project goal, in few sentences: We have small box, running embedded linux with 2 satellite tuners on input and ethernet. Nothing more. We have designed the box for live sat TV/Radio reception, distributing them down to the network. One of the mode of working is "vtuner", what allows reuse those tuners remotely on linux desktop. The kernel part is very simple code exposing kernel's dvb-core to the userspace. Userspace client/server tools do all resource discovery and connection management. It works nicely and guys with vdr who is using it are rather satisfied with it. So, the main goal of vtuner code is to fully virtualize remote DVB adapter. To any linux dvb api compatible applications and tools. The vtuner kernel code seems to be the simplest and straightforward way to achieve it. The company I work for also has something like this. We can attach a DVB tuner to either the Gateway or the STB we provide and use it indifferently , except that we have the following architecture: - a DVB daemon controlling the physical DVB tuner and exposing methods for tuning/scanning/zapping - a web server and web services for accessing the DVB daemon methods - a RTSP streamer with associated methods for controlling streaming The software running on both devices is the same (one compiled for ARM, the other for x86). I do not see any problem with this solution, people wanting to get the stream can still get the RTSP stream directly joining the multicast group, which is fortunately OS agnostic at the same time. I still think the code is very similar to NBD (Network block device) what sits in the kernel and is using silently. I guess NBD also do data copying from/to user space. Is there something what I overlooked? Can you show me the way (hint please) I can initiate TCP connection from within kernel space? If I can do it, then the big disadvantage of data passing to and from kernel can be removed. Don't do this in kernel-space (remember the mechanism/policy split). I must say that the box is primary focused to the DLNA/UpnP world, so vtuner feature is something like interesting addon only. But I was myself very nice surprised how good it behaves on real installations and that was reason I decided to try to get it included in kernel. I see that in present there is no willingness for code acceptation, so I will continue out of the kernel tree. Anyway, if I can find the way how to start TCP connection from the kernel part, I understand it can boost throughput very nicely up. And here is a new hack. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org Mor
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
>> Well, initial report was made on vdr-portal because of our hardware announce, >> but you can be sure the same is true if server is build on any linux >> hardware. >> Here is some note: >> http://www.vdr-portal.de/board18-vdr-hardware/board84-allgemein/106610-das-neue-netzwerk-client-der-f%C3%BCr-vdr-verwenden-k%C3%B6nnen/?highlight=vtuner >> >> Additional info you can find (or ask) on our forum: >> http://forum.nessiedvb.org/forum/viewforum.php?f=11 >> >> Please note, that compilation of vtunerc kernel driver (or loopback, or >> pigback >> or whatever name the code should be used) is simple - no need for any >> kernel real patching is required. Code can be compiled outside of the >> kernel tree >> (of course kernel headers are still needed). >> >> Some useful hints regarding userland application daemons you >> can find in our wiki: >> http://wiki.nessiedvb.org/wiki/doku.php?id=vtuner_mode >> >> When you get vtunerc and vtunerd applications connected, try >> simple command line tuning (szap/tzap or czap) to check >> if it works correctly. Only if you get zapping working switch >> to vdr. > > Thanks for the info and links. I do know many guys who would be > interested in this if it can provide good server/client ability with > VDR. However, a large number of us only speak english so places like > vdr-portal aren't much use a lot of the time. If you have english > forums somewhere, that link would be far more useful I think. No problem. Simply ignore first URL. All others are english :-) I would recommend start from how-it-works-diagram: http://code.google.com/p/vtuner/wiki/BigPicture and then have a look at wiki. where you can some step-by-step info. Anyway, don't hesitate to ask any question in our forum or write me directly. Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Sun, Dec 4, 2011 at 3:22 PM, HoP wrote: > Well, initial report was made on vdr-portal because of our hardware announce, > but you can be sure the same is true if server is build on any linux hardware. > Here is some note: > http://www.vdr-portal.de/board18-vdr-hardware/board84-allgemein/106610-das-neue-netzwerk-client-der-f%C3%BCr-vdr-verwenden-k%C3%B6nnen/?highlight=vtuner > > Additional info you can find (or ask) on our forum: > http://forum.nessiedvb.org/forum/viewforum.php?f=11 > > Please note, that compilation of vtunerc kernel driver (or loopback, or > pigback > or whatever name the code should be used) is simple - no need for any > kernel real patching is required. Code can be compiled outside of the > kernel tree > (of course kernel headers are still needed). > > Some useful hints regarding userland application daemons you > can find in our wiki: > http://wiki.nessiedvb.org/wiki/doku.php?id=vtuner_mode > > When you get vtunerc and vtunerd applications connected, try > simple command line tuning (szap/tzap or czap) to check > if it works correctly. Only if you get zapping working switch > to vdr. Thanks for the info and links. I do know many guys who would be interested in this if it can provide good server/client ability with VDR. However, a large number of us only speak english so places like vdr-portal aren't much use a lot of the time. If you have english forums somewhere, that link would be far more useful I think. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi, > Some input from the sideline reading this discussion. As a FreeBSD'er I would > very much like to see two things happen: > > - vtunerc goes into userspace like a client/server daemon pair using CUSE and > can support _any_ /dev/dvb/adapter, also those created by CUSE itself. That > means I could potentially use vtunerc in FreeBSD with drivers like cx88: Vtuner already has userland client/server pair. The server application is connecting to _any_ /dev/dvb/adapter device. Please look at small picture here: http://code.google.com/p/vtuner/wiki/BigPicture That means the server part is using totally "clean" linux. Nothing more. > > http://corona.homeunix.net/cx88wiki > > - DVB-X solution in Linux gets mmap support to avoid endless copying of data > between kernel and userspace. Adding nmap support should be straightforward. I have it on my TODO. Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Devin, I perfectly remember your opinion regarding vtuner. 2011/12/3 Devin Heitmueller : > On Sat, Dec 3, 2011 at 12:42 PM, Alan Cox wrote: >> On Sat, 3 Dec 2011 09:21:23 -0800 >> VDR User wrote: >> >>> On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter wrote: >>> > You could certainly build a library to reach a different goal. The goal >>> > of vtuner is to access remote tuners with any existing program >>> > implementing the DVB API. >>> >>> So you could finally use VDR as a server/client setup using vtuner, >>> right? With full OSD, timer, etc? Yes, I'm aware that streamdev >>> exists. It was horrible when I tried it last (a long time ago) and I >>> understand it's gotten better. But it's not a suitable replacement for >>> a real server/client setup. It sounds like using vtuner, this would >>> finally be possible and since Klaus has no intention of ever >>> modernizing VDR into server/client (that I'm aware of), it's also the >>> only suitable option as well. >> >> I would expect it to still suck. One of the problems you have with trying >> to pretend things are not networked is that you fake asynchronous events >> synchronously, you can't properly cover error cases and as a result you >> get things like ioctls that hang for two minutes or fail in bogus and >> bizarre ways. If you loop via userspace you've also got to deal with >> deadlocks and all sorts of horrible cornercases like the user space >> daemon dying. >> >> There is a reason properly working client/server code looks different - >> it's not a trivial transformation and faking it kernel side won't be any >> better than faking it in user space - it may well even be a worse fake. >> >> Alan > > This whole notion of creating fake kernel devices to represent > networked tuners feels like a hack. If applications want to access > networked tuners, adding support for RTP/RTSP or incorporating > libhdhomerun (LGPL) is a fairly straightforward exercise. In fact, > many applications already have incorporated support for one of these > two approaches. The fact that app maintainers have been > unwilling/uninterested to do such doesn't feel like it should be an > excuse for hacking this functionality into the kernel. Still the same nonsense - why I should add 10x or even 100 times more code to achieve not the same but may be 80-90% same result? The idea is hell simple = allow to use those remote tuners by 100% of dvb api compliant applications. Not 80%, but 100%. Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi. 2011/12/3 VDR User : > On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter wrote: >> You could certainly build a library to reach a different goal. The goal >> of vtuner is to access remote tuners with any existing program >> implementing the DVB API. > > So you could finally use VDR as a server/client setup using vtuner, > right? With full OSD, timer, etc? Yes, I'm aware that streamdev > exists. It was horrible when I tried it last (a long time ago) and I > understand it's gotten better. But it's not a suitable replacement for > a real server/client setup. It sounds like using vtuner, this would > finally be possible and since Klaus has no intention of ever > modernizing VDR into server/client (that I'm aware of), it's also the > only suitable option as well. > > Or am I wrong about anything? If not, I know several users who would > like to use this, myself included. Well, initial report was made on vdr-portal because of our hardware announce, but you can be sure the same is true if server is build on any linux hardware. Here is some note: http://www.vdr-portal.de/board18-vdr-hardware/board84-allgemein/106610-das-neue-netzwerk-client-der-f%C3%BCr-vdr-verwenden-k%C3%B6nnen/?highlight=vtuner Additional info you can find (or ask) on our forum: http://forum.nessiedvb.org/forum/viewforum.php?f=11 Please note, that compilation of vtunerc kernel driver (or loopback, or pigback or whatever name the code should be used) is simple - no need for any kernel real patching is required. Code can be compiled outside of the kernel tree (of course kernel headers are still needed). Some useful hints regarding userland application daemons you can find in our wiki: http://wiki.nessiedvb.org/wiki/doku.php?id=vtuner_mode When you get vtunerc and vtunerd applications connected, try simple command line tuning (szap/tzap or czap) to check if it works correctly. Only if you get zapping working switch to vdr. Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
> While I agree with your more broad view of the issue, I specifically > talked about VDR. AFAIK Klaus has no intention of adding true > server/client support to VDR, so for VDR users, this sounds like it > could be a working solution without the strict limitations of > streamdev. So fix Klaus rather than mess up the kernel. If you are trying to solve a VDR political problem then kernel hacks are not the way to go. Someone who cares about it needs to fix VDR, with or without its current maintainer. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Sat, Dec 3, 2011 at 3:30 PM, Walter Van Eetvelt wrote: >> So you could finally use VDR as a server/client setup using vtuner, >> right? With full OSD, timer, etc? Yes, I'm aware that streamdev >> exists. It was horrible when I tried it last (a long time ago) and I >> understand it's gotten better. But it's not a suitable replacement for >> a real server/client setup. It sounds like using vtuner, this would >> finally be possible and since Klaus has no intention of ever >> modernizing VDR into server/client (that I'm aware of), it's also the >> only suitable option as well. >> >> Or am I wrong about anything? If not, I know several users who would >> like to use this, myself included. > > This is the question on how you provide (live)tv content to multiple users > and devices. > And I think this goes beyond the simple "second PC in the house" where you > want to watch TV or recordings. How can you watch streams from your DVB > device on your small screen Mobile phone/tablet? Or stream over the > internet and watch your last night recording when commuting in the train? > Some commercial solutions are already available for some scenario's. Also > free software solutions support for some scenario's, but I think still too > limited. > > With that in mind, for me the future is for a client server combination > that can do proper live TV and recording streaming. > And technically, a virtual driver is not bringing better user experience > in the long term I think. On the contrary, some users would use the > vtunerc to fill in some of their needs. This could bring developers to > work less on client/server application supporting a broader range of use > cases. While I agree with your more broad view of the issue, I specifically talked about VDR. AFAIK Klaus has no intention of adding true server/client support to VDR, so for VDR users, this sounds like it could be a working solution without the strict limitations of streamdev. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Sat, 3 Dec 2011 09:21:23 -0800, VDR User wrote: ... > So you could finally use VDR as a server/client setup using vtuner, > right? With full OSD, timer, etc? Yes, I'm aware that streamdev > exists. It was horrible when I tried it last (a long time ago) and I > understand it's gotten better. But it's not a suitable replacement for > a real server/client setup. It sounds like using vtuner, this would > finally be possible and since Klaus has no intention of ever > modernizing VDR into server/client (that I'm aware of), it's also the > only suitable option as well. > > Or am I wrong about anything? If not, I know several users who would > like to use this, myself included. This is the question on how you provide (live)tv content to multiple users and devices. And I think this goes beyond the simple "second PC in the house" where you want to watch TV or recordings. How can you watch streams from your DVB device on your small screen Mobile phone/tablet? Or stream over the internet and watch your last night recording when commuting in the train? Some commercial solutions are already available for some scenario's. Also free software solutions support for some scenario's, but I think still too limited. With that in mind, for me the future is for a client server combination that can do proper live TV and recording streaming. And technically, a virtual driver is not bringing better user experience in the long term I think. On the contrary, some users would use the vtunerc to fill in some of their needs. This could bring developers to work less on client/server application supporting a broader range of use cases. Walter -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi, Some input from the sideline reading this discussion. As a FreeBSD'er I would very much like to see two things happen: - vtunerc goes into userspace like a client/server daemon pair using CUSE and can support _any_ /dev/dvb/adapter, also those created by CUSE itself. That means I could potentially use vtunerc in FreeBSD with drivers like cx88: http://corona.homeunix.net/cx88wiki - DVB-X solution in Linux gets mmap support to avoid endless copying of data between kernel and userspace. --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 03.12.2011 18:42, Alan Cox wrote: > On Sat, 3 Dec 2011 09:21:23 -0800 > VDR User wrote: > >> On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter wrote: >>> You could certainly build a library to reach a different goal. The goal >>> of vtuner is to access remote tuners with any existing program >>> implementing the DVB API. >> >> So you could finally use VDR as a server/client setup using vtuner, >> right? Yes. >> With full OSD, timer, etc? Yes, I'm aware that streamdev >> exists. It was horrible when I tried it last (a long time ago) and I >> understand it's gotten better. But it's not a suitable replacement for >> a real server/client setup. It sounds like using vtuner, this would >> finally be possible and since Klaus has no intention of ever >> modernizing VDR into server/client (that I'm aware of), it's also the >> only suitable option as well. > > I would expect it to still suck. One of the problems you have with trying > to pretend things are not networked is that you fake asynchronous events > synchronously, you can't properly cover error cases and as a result you > get things like ioctls that hang for two minutes or fail in bogus and > bizarre ways. If you loop via userspace you've also got to deal with > deadlocks and all sorts of horrible cornercases like the user space > daemon dying. USB tuners may be removed anytime during any ioctl, too. Handling such error cases is therefore already a requirement, at least for hotplug-capable software. > There is a reason properly working client/server code looks different - > it's not a trivial transformation and faking it kernel side won't be any > better than faking it in user space - it may well even be a worse fake. It's certainly not suitable for every possible use case in the world. For many, however, I think it's the optimal solution. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Sat, Dec 3, 2011 at 12:42 PM, Alan Cox wrote: > On Sat, 3 Dec 2011 09:21:23 -0800 > VDR User wrote: > >> On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter wrote: >> > You could certainly build a library to reach a different goal. The goal >> > of vtuner is to access remote tuners with any existing program >> > implementing the DVB API. >> >> So you could finally use VDR as a server/client setup using vtuner, >> right? With full OSD, timer, etc? Yes, I'm aware that streamdev >> exists. It was horrible when I tried it last (a long time ago) and I >> understand it's gotten better. But it's not a suitable replacement for >> a real server/client setup. It sounds like using vtuner, this would >> finally be possible and since Klaus has no intention of ever >> modernizing VDR into server/client (that I'm aware of), it's also the >> only suitable option as well. > > I would expect it to still suck. One of the problems you have with trying > to pretend things are not networked is that you fake asynchronous events > synchronously, you can't properly cover error cases and as a result you > get things like ioctls that hang for two minutes or fail in bogus and > bizarre ways. If you loop via userspace you've also got to deal with > deadlocks and all sorts of horrible cornercases like the user space > daemon dying. > > There is a reason properly working client/server code looks different - > it's not a trivial transformation and faking it kernel side won't be any > better than faking it in user space - it may well even be a worse fake. > > Alan This whole notion of creating fake kernel devices to represent networked tuners feels like a hack. If applications want to access networked tuners, adding support for RTP/RTSP or incorporating libhdhomerun (LGPL) is a fairly straightforward exercise. In fact, many applications already have incorporated support for one of these two approaches. The fact that app maintainers have been unwilling/uninterested to do such doesn't feel like it should be an excuse for hacking this functionality into the kernel. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Sat, 3 Dec 2011 09:21:23 -0800 VDR User wrote: > On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter wrote: > > You could certainly build a library to reach a different goal. The goal > > of vtuner is to access remote tuners with any existing program > > implementing the DVB API. > > So you could finally use VDR as a server/client setup using vtuner, > right? With full OSD, timer, etc? Yes, I'm aware that streamdev > exists. It was horrible when I tried it last (a long time ago) and I > understand it's gotten better. But it's not a suitable replacement for > a real server/client setup. It sounds like using vtuner, this would > finally be possible and since Klaus has no intention of ever > modernizing VDR into server/client (that I'm aware of), it's also the > only suitable option as well. I would expect it to still suck. One of the problems you have with trying to pretend things are not networked is that you fake asynchronous events synchronously, you can't properly cover error cases and as a result you get things like ioctls that hang for two minutes or fail in bogus and bizarre ways. If you loop via userspace you've also got to deal with deadlocks and all sorts of horrible cornercases like the user space daemon dying. There is a reason properly working client/server code looks different - it's not a trivial transformation and faking it kernel side won't be any better than faking it in user space - it may well even be a worse fake. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 03.12.2011 17:42, Alan Cox wrote: >> FWIW, the virtual DVB device we're talking about doesn't have any >> networking capabilities by itself. It only allows to create virtual DVB >> adapters and to relay DVB API ioctls to userspace in a >> transport-agnostic way. > > Which you can do working from CUSE already, as has been pointed out or > with LD_PRELOAD. This btw makes the proprietary thing seem a rather odd > objection - they could do it too. Yes, both CUSE and LD_PRELOADED have already been suggested. But I already explained in previous mails why both options are unsuitable: - For LD_PRELOAD to intercept any calls to open, ioctl, read, write, the character device to be intercepted must exist first. But it doesn't exist, unless it was created by vtuner first. Of course you could also intercept stat(), readdir() and all other possible functions to list or access devices and fake entries, but I hope you're not suggesting this seriously. Well, proprietary drivers doing that already exist today (e.g. by sundtek), but implementing somthing like that if an easier solution is possible would be crazy at best. Additionaly, preloaded libraries conflict with other preloaded libraries overwriting the same functions. Preloaded libraries don't work with statically linked programs. Preloaded libraries can't be used transparently, because you need to edit init scripts to use them, unless you want them to be used globally (in /etc/ld.so.preload). - CUSE would conflict with dvb-core. Once CUSE created a DVB adapter, registering another non-virtual DVB adapter (by plugging in a USB device for example) will try to assign the same adapter number. The following only applies to the original version of the interface, but is likely to apply to future development of the proposed interface: In order to add virtual tuners to existing DVB adapters, to be able to use their hardware demux or MPEG decoders with CUSE, the whole device driver of this adapter has to be implemented in userspace. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter wrote: > You could certainly build a library to reach a different goal. The goal > of vtuner is to access remote tuners with any existing program > implementing the DVB API. So you could finally use VDR as a server/client setup using vtuner, right? With full OSD, timer, etc? Yes, I'm aware that streamdev exists. It was horrible when I tried it last (a long time ago) and I understand it's gotten better. But it's not a suitable replacement for a real server/client setup. It sounds like using vtuner, this would finally be possible and since Klaus has no intention of ever modernizing VDR into server/client (that I'm aware of), it's also the only suitable option as well. Or am I wrong about anything? If not, I know several users who would like to use this, myself included. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
> FWIW, the virtual DVB device we're talking about doesn't have any > networking capabilities by itself. It only allows to create virtual DVB > adapters and to relay DVB API ioctls to userspace in a > transport-agnostic way. Which you can do working from CUSE already, as has been pointed out or with LD_PRELOAD. This btw makes the proprietary thing seem a rather odd objection - they could do it too. > The original version of the vtuner interface makes use of demux hardware > and also feeds the relevant streams to a/v decoders, in which case you > cannot avoid copying the MPEG data to kernel space. Right and that aspect of it actually makes a lot more sense to me, because receive and decode/playback are different functional units. But jumping up and down arguing about how you want to name the code isn't going to produce a productive result To answer the other question posed by "HoP" - yes you can do TCP from kernel space. We need this for things like NFS, CIFS etc. That might well be valuable especially for low end hardware. The best code to read is probably the net/sunrpc code to get an idea of how it ends up looking. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hello Alan, On 03.12.2011 00:19, Alan Cox wrote: > On Thu, 1 Dec 2011 15:58:41 +0100 > HoP wrote: > >> Hi, >> >> let me ask you some details of your interesting idea (how to >> achieve the same functionality as with vtunerc driver): >> >> [...] >> >>> The driver, as proposed, is not really a driver, as it doesn't support any >>> hardware. The kernel driver would be used to just copy data from one >>> userspace >> >> Please stop learning me what can be called driver and what nope. >> Your definition is nonsense and I don't want to follow you on it. > > You can stick your fingers in your ears and shout all you like but given > Mauro is the maintainer I'd suggest you work with him rather than making > it painful. One of the failures we routinely exclude code from the kernel > for is best described as "user interface of contributor" > > It's a loopback that adds a performance hit. The right way to do this is > in userspace with the userspace infrastructure. At that point you can > handle all the corner cases properly, integrate things like service > discovery into your model and so on - stuff you'll never get to work that > well with kernel loopback hackery. FWIW, the virtual DVB device we're talking about doesn't have any networking capabilities by itself. It only allows to create virtual DVB adapters and to relay DVB API ioctls to userspace in a transport-agnostic way. Networking already takes place in a separate userspace process. >> Can you show me, how then can be reused most important part >> of dvb-core subsystem like tuning and demuxing? Or do you want me >> to invent wheels and to recode everything in the library? Of course > > You could certainly build a library from the same code. That might well > be a good thing for all kinds of 'soft' DV applications. At that point > the discussion to have is the best way to make that code sharable between > a userspace library and the kernel and buildable for both. You could certainly build a library to reach a different goal. The goal of vtuner is to access remote tuners with any existing program implementing the DVB API. One of my primary use cases is to develop DVB API software on my notebook, while receiving the data from an embedded device, so I don't need an antenna cable connected to my notebook (or don't need to have an antenna at my location at all, if an internet connection is available). Another use case is to receive data streams over the internet from satellite, cable and terrestrial networks that are impossible to receive in my area to verify that my DVB API software works with those streams. Furthermore, I'd like to use standard tools implementing theDid you even unders DVB API, e.g. to scan for channels, to measure signal quality or to decode streams on remote locations. With vtuner, and an accompanying open source networking daemon, all of the above works out of the box. If I'd like to change the way data gets relayed between hosts (e.g. add IPv6 or SSL), I'd just need to update the userspace client and server. With a library, I'd need to implement networking in every little DVB API tool I want to use, multiplying the code size of every tool, restricting each tool to some arbitrarily chosen network protocol. If I'd like to change the way data gets relayed between hosts, I'd need to update every application using it. >> I can be wrong, I'm no big kernel hacker. So please show me the >> way for it. BTW, even if you can find the way, then data copying >> from userspace to the kernel and back is also necessery. I really >> don't see any advantage of you solution. > > In a properly built media subsystem you shouldn't need any copies beyond > those that naturally occur as part of a processing pass and are therefore > free. The original version of the vtuner interface makes use of demux hardware and also feeds the relevant streams to a/v decoders, in which case you cannot avoid copying the MPEG data to kernel space. That's also the way to playback local DVB recordings works today without vtuners. I'm fine with not merging this code, if there are technical arguments against it. And personally I don't need it to be merged to be able to use it. However, Mauro invents half-baked arguments against it, because he fears that the code may be "abused" by closed-source userspace drivers (he already declared the latter publicly on the linux-media list). Unfortunately, I must assume that your own arguments are based on Mauro's emails instead of on the source code, because you clearly didn't understand the architecture of vtuner, regarding what's supposed to happen in kernel space and what not. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi Alan. 2011/12/3 Alan Cox : > On Thu, 1 Dec 2011 15:58:41 +0100 > HoP wrote: > >> Hi, >> >> let me ask you some details of your interesting idea (how to >> achieve the same functionality as with vtunerc driver): >> >> [...] >> >> > The driver, as proposed, is not really a driver, as it doesn't support any >> > hardware. The kernel driver would be used to just copy data from one >> > userspace >> >> Please stop learning me what can be called driver and what nope. >> Your definition is nonsense and I don't want to follow you on it. > > You can stick your fingers in your ears and shout all you like but given > Mauro is the maintainer I'd suggest you work with him rather than making > it painful. One of the failures we routinely exclude code from the kernel > for is best described as "user interface of contributor" You may be not read all my mails but I really tried to be very positive in them. I wanted to focus on my Subject, but Mauro has, sometimes, the demand to focus on insignificant things (like if the code is driver or not). At least it is my feeling from all those disscussions with him. > > It's a loopback that adds a performance hit. The right way to do this is > in userspace with the userspace infrastructure. At that point you can > handle all the corner cases properly, integrate things like service > discovery into your model and so on - stuff you'll never get to work that > well with kernel loopback hackery. > >> Can you show me, how then can be reused most important part >> of dvb-core subsystem like tuning and demuxing? Or do you want me >> to invent wheels and to recode everything in the library? Of course > > You could certainly build a library from the same code. That might well > be a good thing for all kinds of 'soft' DV applications. At that point > the discussion to have is the best way to make that code sharable between > a userspace library and the kernel and buildable for both. > >> I can be wrong, I'm no big kernel hacker. So please show me the >> way for it. BTW, even if you can find the way, then data copying >> from userspace to the kernel and back is also necessery. I really >> don't see any advantage of you solution. > > In a properly built media subsystem you shouldn't need any copies beyond > those that naturally occur as part of a processing pass and are therefore > free. I may describe project goal, in few sentences: We have small box, running embedded linux with 2 satellite tuners on input and ethernet. Nothing more. We have designed the box for live sat TV/Radio reception, distributing them down to the network. One of the mode of working is "vtuner", what allows reuse those tuners remotely on linux desktop. The kernel part is very simple code exposing kernel's dvb-core to the userspace. Userspace client/server tools do all resource discovery and connection management. It works nicely and guys with vdr who is using it are rather satisfied with it. So, the main goal of vtuner code is to fully virtualize remote DVB adapter. To any linux dvb api compatible applications and tools. The vtuner kernel code seems to be the simplest and straightforward way to achieve it. I still think the code is very similar to NBD (Network block device) what sits in the kernel and is using silently. I guess NBD also do data copying from/to user space. Is there something what I overlooked? Can you show me the way (hint please) I can initiate TCP connection from within kernel space? If I can do it, then the big disadvantage of data passing to and from kernel can be removed. I must say that the box is primary focused to the DLNA/UpnP world, so vtuner feature is something like interesting addon only. But I was myself very nice surprised how good it behaves on real installations and that was reason I decided to try to get it included in kernel. I see that in present there is no willingness for code acceptation, so I will continue out of the kernel tree. Anyway, if I can find the way how to start TCP connection from the kernel part, I understand it can boost throughput very nicely up. Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Thu, 1 Dec 2011 15:58:41 +0100 HoP wrote: > Hi, > > let me ask you some details of your interesting idea (how to > achieve the same functionality as with vtunerc driver): > > [...] > > > The driver, as proposed, is not really a driver, as it doesn't support any > > hardware. The kernel driver would be used to just copy data from one > > userspace > > Please stop learning me what can be called driver and what nope. > Your definition is nonsense and I don't want to follow you on it. You can stick your fingers in your ears and shout all you like but given Mauro is the maintainer I'd suggest you work with him rather than making it painful. One of the failures we routinely exclude code from the kernel for is best described as "user interface of contributor" It's a loopback that adds a performance hit. The right way to do this is in userspace with the userspace infrastructure. At that point you can handle all the corner cases properly, integrate things like service discovery into your model and so on - stuff you'll never get to work that well with kernel loopback hackery. > Can you show me, how then can be reused most important part > of dvb-core subsystem like tuning and demuxing? Or do you want me > to invent wheels and to recode everything in the library? Of course You could certainly build a library from the same code. That might well be a good thing for all kinds of 'soft' DV applications. At that point the discussion to have is the best way to make that code sharable between a userspace library and the kernel and buildable for both. > I can be wrong, I'm no big kernel hacker. So please show me the > way for it. BTW, even if you can find the way, then data copying > from userspace to the kernel and back is also necessery. I really > don't see any advantage of you solution. In a properly built media subsystem you shouldn't need any copies beyond those that naturally occur as part of a processing pass and are therefore free. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
> What really surprised me badly was that when I read all 54 responses > I have counted only two real technical answers!!! All rest were about > POLITICAL issues - code was NACKed w/o any technical discussion. > Because of fear of possible abusing of driver. To answer the original question -- absolutely not! Linux is not about and should not try policing what it's users do, or passing moral judgment. If there are technical reasons something shouldn't be merged as is, no problem. There are times when a persons personal preference should be left out of the equation, and this is an example of one. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 02.12.2011 19:16, Andreas Oberritter wrote: > On 02.12.2011 18:49, Rémi Denis-Courmont wrote: >> Le jeudi 1 décembre 2011 21:59:56 HoP, vous avez écrit : Kernel code is GPLv2. You can use its code on a GPLv2 licensed library. >>> >>> I see. So if you think it is nice to get dvb-core, make a wrapper around >>> to get it usable in userspace and maintain totally same functionality >>> by myself then I say it is no go. If it looks for you like good idea >>> I must disagree. Code duplication? >> >> Sure, some core code would be duplicated. That is not a big deal. >> >> This proposal however has three big advantages: >> - Proprietary drivers are not enabled as the library would be GPL. >> - The virtual DVB device runs in the same process as the DVB application, >> which saves context switching and memory copying. >> - It would be your project. You do not need to agree with Mauro ;-) >> >>> Two maintaners? That is crazy idea man. >> >> Someone would have to maintain the device driver anyway. I don't see much of >> a >> difference on maintainance side. >> And I can't see any advantage on yours ;) Putting something that belongs to userspace into kernelspace just because it is easier to re-use the existing code inside the kernel is not a good argument. >>> >>> It is only your POV that it should be in userspace.Also, LGPL drivers >> >> Except for backward compatiblity, this would actually belong in userspace. >> It >> would be more efficient and easier to maintain as a userspace library than >> as >> a kernel driver. > > Maintaining the kernel module would be rather easy, because new > properties added to dvb_frontend would be handled transparently. The > implementation is quite simple. In contrast, implementing and then > maintaining all the users of a newly written userspace library would be > a nightmare in comparison. > >> If you need backward compatibility, I am still inclined to believe that you >> could write a CUSE frontend, so it does involve some extra work and looses >> the >> performance benefit. One more note: CUSE would conflict with dvb-core the same way Mauro's sockets would do. > How would all this allow to use e.g. dvbsnoop or w_scan on a remote > tuner? Do you propose to add a dependency to this proposed library to > every application? > > Furthermore, a GPLv2 library would artificially restrict its users, e.g. > you wouldn't be allowed to use it with gstreamer or just with anything > that isn't GPLv2, not even v3. > > Regards, > Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 02.12.2011 18:49, Rémi Denis-Courmont wrote: > Le jeudi 1 décembre 2011 21:59:56 HoP, vous avez écrit : >>> Kernel code is GPLv2. You can use its code on a GPLv2 licensed library. >> >> I see. So if you think it is nice to get dvb-core, make a wrapper around >> to get it usable in userspace and maintain totally same functionality >> by myself then I say it is no go. If it looks for you like good idea >> I must disagree. Code duplication? > > Sure, some core code would be duplicated. That is not a big deal. > > This proposal however has three big advantages: > - Proprietary drivers are not enabled as the library would be GPL. > - The virtual DVB device runs in the same process as the DVB application, > which saves context switching and memory copying. > - It would be your project. You do not need to agree with Mauro ;-) > >> Two maintaners? That is crazy idea man. > > Someone would have to maintain the device driver anyway. I don't see much of > a > difference on maintainance side. > >>> And I can't see any advantage on yours ;) Putting something that belongs >>> to userspace into kernelspace just because it is easier to re-use the >>> existing code inside the kernel is not a good argument. >> >> It is only your POV that it should be in userspace.Also, LGPL drivers > > Except for backward compatiblity, this would actually belong in userspace. It > would be more efficient and easier to maintain as a userspace library than as > a kernel driver. Maintaining the kernel module would be rather easy, because new properties added to dvb_frontend would be handled transparently. The implementation is quite simple. In contrast, implementing and then maintaining all the users of a newly written userspace library would be a nightmare in comparison. > If you need backward compatibility, I am still inclined to believe that you > could write a CUSE frontend, so it does involve some extra work and looses > the > performance benefit. How would all this allow to use e.g. dvbsnoop or w_scan on a remote tuner? Do you propose to add a dependency to this proposed library to every application? Furthermore, a GPLv2 library would artificially restrict its users, e.g. you wouldn't be allowed to use it with gstreamer or just with anything that isn't GPLv2, not even v3. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Le jeudi 1 décembre 2011 21:59:56 HoP, vous avez écrit : > > Kernel code is GPLv2. You can use its code on a GPLv2 licensed library. > > I see. So if you think it is nice to get dvb-core, make a wrapper around > to get it usable in userspace and maintain totally same functionality > by myself then I say it is no go. If it looks for you like good idea > I must disagree. Code duplication? Sure, some core code would be duplicated. That is not a big deal. This proposal however has three big advantages: - Proprietary drivers are not enabled as the library would be GPL. - The virtual DVB device runs in the same process as the DVB application, which saves context switching and memory copying. - It would be your project. You do not need to agree with Mauro ;-) > Two maintaners? That is crazy idea man. Someone would have to maintain the device driver anyway. I don't see much of a difference on maintainance side. > > And I can't see any advantage on yours ;) Putting something that belongs > > to userspace into kernelspace just because it is easier to re-use the > > existing code inside the kernel is not a good argument. > > It is only your POV that it should be in userspace. Except for backward compatiblity, this would actually belong in userspace. It would be more efficient and easier to maintain as a userspace library than as a kernel driver. If you need backward compatibility, I am still inclined to believe that you could write a CUSE frontend, so it does involve some extra work and looses the performance benefit. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 02-12-2011 09:57, HoP wrote: If you want to disscuss, No, I don't want. There are architectural issues on your solution. As I said, from the Kernel POV, just the network drivers is enough to run *any* client-server solution on any OS that uses the TCP/IP stack. All streaming applications (DVB or not) have their solution without requiring any virtual driver, using the TCP/IP stack. You still think that your solution is technically better than theirs. So, we agree do disagree on that matter. From my side, I won't merge it due to the already explained reasons. Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Fri, 02 Dec 2011 12:48:35 +0100, Andreas Oberritter wrote: >> Btw, applications like vdr, vlc, kaffeine and others already implement >> their >> own ways to remotelly access the DVB devices without requiring any >> kernelspace piggyback driver. > > Can vdr, vlc, kaffeine use remote tuners on hosts not running vdr, vlc > or kaffeine? Should we implement networking protocols in scan, w_scan, > czap, tzap, szap, mplayer, dvbsnoop, dvbstream, etc. instead? VLC does not support remote control of digital (nor analog) tuners as of today. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
[...] >>> you failed to convince >>> people >>> why this can't be implemented on userspace, >> >> Wrong. You failed to convince people why this must be implemented in >> userspace. Even Michael Krufky, who's "only" against merging it, likes >> the idea, because it's useful. > > Sometimes, when I'm debugging a driver, I use to add several hacks inside > the kernelspace, in order to do things that are useful on my development > (debug printk's, dirty hacks, etc). I even have my own set of patches that > I apply on kvm, in order to sniff PCI traffic. This doesn't mean that > I should send all those crap upstream. If you want to disscuss, please better use wordings. Even my Subject was not about endless discussion that your userspace aproach is better (me, Andreas and few others doesn't agree with you, it is your own POV, nobody follows you, if you not noted) don't be so offensive regarding my code. I don't thing it is so crap. > >> Just because something can be implemented in userspace doesn't mean that >> it's technically superior. > > True, but I didn't see anything at the submitted code or at the discussions > showing that implementing it in kernelspace is technically superior. > > What I'm seeing is what is coded there: > > http://code.google.com/p/vtuner/ > > The kernelspace part is just a piggyback driver, that just copies data > from/to > the dvb calls into another device, that sends the request back to userspace. > > A separate userspace daemon will get such results and send to the network > stack: > > http://code.google.com/p/vtuner/source/browse/vtuner-network.c?repo=apps > > This is technically inferior of letting the application just talk to vtuner > directly via some library call. > > Btw, applications like vdr, vlc, kaffeine and others already implement their > own ways to remotelly access the DVB devices without requiring any > kernelspace piggyback driver. This in not only about well-known "fatty" applications like vdr, kaffeine etc. Using vtunerc allows to use any dvb api compatible tools. Like tools from dvb-tools package (szap/dvbsnoop/...) There is no more general way of having dvb adapter virtualized. > >>> the driver adds hooks at >>> kernelspace >>> that would open internal API's that several developers don't agree on >>> exposing >>> at userspace, as would allow non GPL license compatible drivers to re-use >>> their work in a way they are against. >> >> What's left is your unreasonable GPL blah blah. So the answer to Honza's >> question is: Yes, Mauro is nacking the driver because he's worrying >> about possible misuse. Well, yes. I feel the same what wrote Andreas. The only pity is that nobody from outside linuxm-media need to comment that. Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 02.12.2011 12:14, Mauro Carvalho Chehab wrote:
> On 01-12-2011 20:55, Andreas Oberritter wrote:
>> On 01.12.2011 21:38, Mauro Carvalho Chehab wrote:
>>> I fail to see where do you need to duplicate dvb-core. An userspace
>>> LD_PRELOAD handler that would do:
>>>
>>> int socket;
>>>
>>> int dvb_ioctl(int fd, unsigned long int request, ...)
>>> {
>>> void *arg;
>>> va_list ap;
>>>
>>> va_start(ap, request);
>>> arg = va_arg(ap, void *);
>>> va_end(ap);
>>>
>>> send_net_ioctl_packet(socket, request, arg);
>>> }
>>>
>>> Is probably all you need to send _any_ ioctl's to a remote machine
>>> (plus client's machine that would decode the ioctl packet and send
>>> the ioctl to the actual driver).
>>>
>>> Of course, you'll need hooks for all syscalls used (likely open, close,
>>> ioctl, read, poll).
>>>
>>> So, there's not much duplication, even if, for whatever reason, you
>>> might need to hook some specific ioctls in order to optimize the
>>> network performance.
>>
>> Mauro, we've already had that discussion last time. In order to
>> intercept ioctls of a device, the device needs to exist to begin with,
>> right? That's where vtuner comes in: It creates the virtual device.
>
> Yes.
>
>> For that reason your suggested approach using LD_PRELOAD won't work.
>
> If you're referring to the device name under /dev, a daemon emulating
> a physical device could create Unix sockets under /dev/dvb.
This won't work either, as it would conflict with kernel device
management. Furthermore, programs will detect that a socket is not a
character device.
> Or (with is the right solution) bind such library into the applications
> that will be used.
You mean "such" libraries broken by design?
>> Besides that, suggesting LD_PRELOAD for something other than a hack
>> can't be taken seriously.
>
> A Kernel pigback plugin is also a hack.
Inventing random terms doen't help. Even if you consider it a hack,
you're one of very few people to do so. So it's a better hack than using
LD_PRELOAD. Btw., since when are kernel modules called plugins?
>> I think you didn't even understand what vtuner does, after all the
>> discussion that took place.
>>
>> Of course
>> I can be wrong, I'm no big kernel hacker. So please show me the
>> way for it. BTW, even if you can find the way, then data copying
>> from userspace to the kernel and back is also necessery.
>
> See libv4l, at v4l2-utils.git (at linuxtv.org).
>
>> I really
>> don't see any advantage of you solution.
>
> And I can't see any advantage on yours ;) Putting something that
> belongs
> to userspace into kernelspace just because it is easier to re-use the
> existing code inside the kernel is not a good argument.
It is only your POV that it should be in userspace.
Creating additional code which not only enlarge code size by 2
but I think by 10 is really not good idea. And it get no advantage
only disadvantages.
>
> Don't get me wrong but if you want to submit a code to be merged
> on any existing software (being open source or not), you should be
> prepared to defend your code and justify the need for it to the
> other developers.
Sure. I was prepared for technical disscussion, but was fully suprised
that it was not happend (ok, to be correct, few guys are exception,
like
Andreas and few others. I really appreciate it).
So, my question was still not answered: "Can be driver NACKed only
because of worrying about possible misuse?"
>>>
>>> To answer your question: your driver were nacked because of several
>>> reasons:
>>> it is not a driver for an unsupported hardware,
>>
>> It's not a driver for supported hardware either. You named it before:
>> It's not a driver in your definition at all. It's a way to remotely
>> access digital TV tuners over a network.
>
> Yes, this is not a driver. It is just a hack to avoid adding network
> support at the userspace applications.
One could argue about the term hack, but yes, exactly, that's what it
is. And this is a very good feature.
>>> you failed to convince
>>> people
>>> why this can't be implemented on userspace,
>>
>> Wrong. You failed to convince people why this must be implemented in
>> userspace. Even Michael Krufky, who's "only" against merging it, likes
>> the idea, because it's useful.
>
> Sometimes, when I'm debugging a driver, I use to add several hacks inside
> the kernelspace, in order to do things that are useful on my development
> (debug printk's, dirty hacks, etc). I even have my own set of patches that
> I apply on kvm, in order to sniff PCI traffic. This doesn't mean that
> I should send all those crap upstream.
That's a nice story, but it's a completely different topic.
>> Just because something can be implemented in userspace doesn't mean that
>> it's technically superior.
>
> True, but I didn't see anything at th
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Fri, 02 Dec 2011 09:14:47 -0200, Mauro Carvalho Chehab wrote: > If you're referring to the device name under /dev, a daemon emulating > a physical device could create Unix sockets under /dev/dvb. Hmm, how would that work if a real physical device gets added afterward and udev wants to create the nodes? -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 01-12-2011 20:55, Andreas Oberritter wrote:
On 01.12.2011 21:38, Mauro Carvalho Chehab wrote:
I fail to see where do you need to duplicate dvb-core. An userspace
LD_PRELOAD handler that would do:
int socket;
int dvb_ioctl(int fd, unsigned long int request, ...)
{
void *arg;
va_list ap;
va_start(ap, request);
arg = va_arg(ap, void *);
va_end(ap);
send_net_ioctl_packet(socket, request, arg);
}
Is probably all you need to send _any_ ioctl's to a remote machine
(plus client's machine that would decode the ioctl packet and send
the ioctl to the actual driver).
Of course, you'll need hooks for all syscalls used (likely open, close,
ioctl, read, poll).
So, there's not much duplication, even if, for whatever reason, you
might need to hook some specific ioctls in order to optimize the
network performance.
Mauro, we've already had that discussion last time. In order to
intercept ioctls of a device, the device needs to exist to begin with,
right? That's where vtuner comes in: It creates the virtual device.
Yes.
For that reason your suggested approach using LD_PRELOAD won't work.
If you're referring to the device name under /dev, a daemon emulating
a physical device could create Unix sockets under /dev/dvb.
Or (with is the right solution) bind such library into the applications
that will be used.
Besides that, suggesting LD_PRELOAD for something other than a hack
can't be taken seriously.
A Kernel pigback plugin is also a hack.
I think you didn't even understand what vtuner does, after all the
discussion that took place.
Of course
I can be wrong, I'm no big kernel hacker. So please show me the
way for it. BTW, even if you can find the way, then data copying
from userspace to the kernel and back is also necessery.
See libv4l, at v4l2-utils.git (at linuxtv.org).
I really
don't see any advantage of you solution.
And I can't see any advantage on yours ;) Putting something that belongs
to userspace into kernelspace just because it is easier to re-use the
existing code inside the kernel is not a good argument.
It is only your POV that it should be in userspace.
Creating additional code which not only enlarge code size by 2
but I think by 10 is really not good idea. And it get no advantage
only disadvantages.
Don't get me wrong but if you want to submit a code to be merged
on any existing software (being open source or not), you should be
prepared to defend your code and justify the need for it to the
other developers.
Sure. I was prepared for technical disscussion, but was fully suprised
that it was not happend (ok, to be correct, few guys are exception, like
Andreas and few others. I really appreciate it).
So, my question was still not answered: "Can be driver NACKed only
because of worrying about possible misuse?"
To answer your question: your driver were nacked because of several
reasons:
it is not a driver for an unsupported hardware,
It's not a driver for supported hardware either. You named it before:
It's not a driver in your definition at all. It's a way to remotely
access digital TV tuners over a network.
Yes, this is not a driver. It is just a hack to avoid adding network
support at the userspace applications.
you failed to convince
people
why this can't be implemented on userspace,
Wrong. You failed to convince people why this must be implemented in
userspace. Even Michael Krufky, who's "only" against merging it, likes
the idea, because it's useful.
Sometimes, when I'm debugging a driver, I use to add several hacks inside
the kernelspace, in order to do things that are useful on my development
(debug printk's, dirty hacks, etc). I even have my own set of patches that
I apply on kvm, in order to sniff PCI traffic. This doesn't mean that
I should send all those crap upstream.
Just because something can be implemented in userspace doesn't mean that
it's technically superior.
True, but I didn't see anything at the submitted code or at the discussions
showing that implementing it in kernelspace is technically superior.
What I'm seeing is what is coded there:
http://code.google.com/p/vtuner/
The kernelspace part is just a piggyback driver, that just copies data from/to
the dvb calls into another device, that sends the request back to userspace.
A separate userspace daemon will get such results and send to the network stack:
http://code.google.com/p/vtuner/source/browse/vtuner-network.c?repo=apps
This is technically inferior of letting the application just talk to vtuner
directly via some library call.
Btw, applications like vdr, vlc, kaffeine and others already implement their
own ways to remotelly access the DVB devices without requiring any
kernelspace piggyback driver.
the driver adds hooks at
kernelspace
that would open internal API's that several developers don't agree on
exposing
at userspace, as would allow non GPL license compatible drivers to re-use
their work in a way they ar
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 01.12.2011 21:38, Mauro Carvalho Chehab wrote:
> I fail to see where do you need to duplicate dvb-core. An userspace
> LD_PRELOAD handler that would do:
>
> int socket;
>
> int dvb_ioctl(int fd, unsigned long int request, ...)
> {
> void *arg;
> va_list ap;
>
> va_start(ap, request);
> arg = va_arg(ap, void *);
> va_end(ap);
>
> send_net_ioctl_packet(socket, request, arg);
> }
>
> Is probably all you need to send _any_ ioctl's to a remote machine
> (plus client's machine that would decode the ioctl packet and send
> the ioctl to the actual driver).
>
> Of course, you'll need hooks for all syscalls used (likely open, close,
> ioctl, read, poll).
>
> So, there's not much duplication, even if, for whatever reason, you
> might need to hook some specific ioctls in order to optimize the
> network performance.
Mauro, we've already had that discussion last time. In order to
intercept ioctls of a device, the device needs to exist to begin with,
right? That's where vtuner comes in: It creates the virtual device.
For that reason your suggested approach using LD_PRELOAD won't work.
Besides that, suggesting LD_PRELOAD for something other than a hack
can't be taken seriously.
I think you didn't even understand what vtuner does, after all the
discussion that took place.
Of course
I can be wrong, I'm no big kernel hacker. So please show me the
way for it. BTW, even if you can find the way, then data copying
from userspace to the kernel and back is also necessery.
>>>
>>> See libv4l, at v4l2-utils.git (at linuxtv.org).
>>>
I really
don't see any advantage of you solution.
>>>
>>> And I can't see any advantage on yours ;) Putting something that belongs
>>> to userspace into kernelspace just because it is easier to re-use the
>>> existing code inside the kernel is not a good argument.
>>
>> It is only your POV that it should be in userspace.
>>
>> Creating additional code which not only enlarge code size by 2
>> but I think by 10 is really not good idea. And it get no advantage
>> only disadvantages.
>>
>>>
>>> Don't get me wrong but if you want to submit a code to be merged
>>> on any existing software (being open source or not), you should be
>>> prepared to defend your code and justify the need for it to the
>>> other developers.
>>
>> Sure. I was prepared for technical disscussion, but was fully suprised
>> that it was not happend (ok, to be correct, few guys are exception, like
>> Andreas and few others. I really appreciate it).
>>
>> So, my question was still not answered: "Can be driver NACKed only
>> because of worrying about possible misuse?"
>
> To answer your question: your driver were nacked because of several
> reasons:
> it is not a driver for an unsupported hardware,
It's not a driver for supported hardware either. You named it before:
It's not a driver in your definition at all. It's a way to remotely
access digital TV tuners over a network.
> you failed to convince
> people
> why this can't be implemented on userspace,
Wrong. You failed to convince people why this must be implemented in
userspace. Even Michael Krufky, who's "only" against merging it, likes
the idea, because it's useful.
Just because something can be implemented in userspace doesn't mean that
it's technically superior.
> the driver adds hooks at
> kernelspace
> that would open internal API's that several developers don't agree on
> exposing
> at userspace, as would allow non GPL license compatible drivers to re-use
> their work in a way they are against.
What's left is your unreasonable GPL blah blah. So the answer to Honza's
question is: Yes, Mauro is nacking the driver because he's worrying
about possible misuse.
Regards,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 01-12-2011 17:59, HoP wrote:
2011/12/1 Mauro Carvalho Chehab:
On 01-12-2011 12:58, HoP wrote:
Hi,
let me ask you some details of your interesting idea (how to
achieve the same functionality as with vtunerc driver):
[...]
The driver, as proposed, is not really a driver, as it doesn't support
any
hardware. The kernel driver would be used to just copy data from one
userspace
Please stop learning me what can be called driver and what nope.
Your definition is nonsense and I don't want to follow you on it.
application to the other. The same result could be obtained in userspace,
by implementing a library. Such library could even use LD_PRELOAD to
support
binary only applications, like what libv4l does. In terms of performance,
such library would probably perform better than a kernel driver, as
there's
no need to do context switching for each call, and no need to talk with a
device (where kernel outperforms userspace). Also, depending on how such
library
is implemented, double buffering might be avoided.
So, from architectural POV, this code should be written as an userspace
library.
BTW, alsa also came with the same results, years ago, as audio remote
streaming is supported via userspace tools, like pulseaudio.
Can you show me, how then can be reused most important part
of dvb-core subsystem like tuning and demuxing?
Why do you need to implement it? Just forward the requests to the machine
with the real driver.
Or do you want me
to invent wheels and to recode everything in the library?
Kernel code is GPLv2. You can use its code on a GPLv2 licensed library.
I see. So if you think it is nice to get dvb-core, make a wrapper around
to get it usable in userspace and maintain totally same functionality
by myself then I say it is no go. If it looks for you like good idea
I must disagree. Code duplication? Two maintaners? That is crazy idea man.
I fail to see where do you need to duplicate dvb-core. An userspace
LD_PRELOAD handler that would do:
int socket;
int dvb_ioctl(int fd, unsigned long int request, ...)
{
void *arg;
va_list ap;
va_start(ap, request);
arg = va_arg(ap, void *);
va_end(ap);
send_net_ioctl_packet(socket, request, arg);
}
Is probably all you need to send _any_ ioctl's to a remote machine
(plus client's machine that would decode the ioctl packet and send
the ioctl to the actual driver).
Of course, you'll need hooks for all syscalls used (likely open, close,
ioctl, read, poll).
So, there's not much duplication, even if, for whatever reason, you
might need to hook some specific ioctls in order to optimize the
network performance.
Of course
I can be wrong, I'm no big kernel hacker. So please show me the
way for it. BTW, even if you can find the way, then data copying
from userspace to the kernel and back is also necessery.
See libv4l, at v4l2-utils.git (at linuxtv.org).
I really
don't see any advantage of you solution.
And I can't see any advantage on yours ;) Putting something that belongs
to userspace into kernelspace just because it is easier to re-use the
existing code inside the kernel is not a good argument.
It is only your POV that it should be in userspace.
Creating additional code which not only enlarge code size by 2
but I think by 10 is really not good idea. And it get no advantage
only disadvantages.
Don't get me wrong but if you want to submit a code to be merged
on any existing software (being open source or not), you should be
prepared to defend your code and justify the need for it to the
other developers.
Sure. I was prepared for technical disscussion, but was fully suprised
that it was not happend (ok, to be correct, few guys are exception, like
Andreas and few others. I really appreciate it).
So, my question was still not answered: "Can be driver NACKed only
because of worrying about possible misuse?"
To answer your question: your driver were nacked because of several reasons:
it is not a driver for an unsupported hardware, you failed to convince people
why this can't be implemented on userspace, the driver adds hooks at kernelspace
that would open internal API's that several developers don't agree on exposing
at userspace, as would allow non GPL license compatible drivers to re-use
their work in a way they are against.
You're free to politely argue with regards to your solution at the ML.
From my side, due to already explained technical reasons, I nack the
current approach. I'm free to not comment it further, while there's
no new fact that would convince me otherwise.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
2011/12/1 Mauro Carvalho Chehab : > On 01-12-2011 12:58, HoP wrote: >> >> Hi, >> >> let me ask you some details of your interesting idea (how to >> achieve the same functionality as with vtunerc driver): >> >> [...] >> >>> The driver, as proposed, is not really a driver, as it doesn't support >>> any >>> hardware. The kernel driver would be used to just copy data from one >>> userspace >> >> Please stop learning me what can be called driver and what nope. >> Your definition is nonsense and I don't want to follow you on it. >> >>> application to the other. The same result could be obtained in userspace, >>> by implementing a library. Such library could even use LD_PRELOAD to >>> support >>> binary only applications, like what libv4l does. In terms of performance, >>> such library would probably perform better than a kernel driver, as >>> there's >>> no need to do context switching for each call, and no need to talk with a >>> device (where kernel outperforms userspace). Also, depending on how such >>> library >>> is implemented, double buffering might be avoided. >>> >>> So, from architectural POV, this code should be written as an userspace >>> library. >>> BTW, alsa also came with the same results, years ago, as audio remote >>> streaming is supported via userspace tools, like pulseaudio. >> >> Can you show me, how then can be reused most important part >> of dvb-core subsystem like tuning and demuxing? > > Why do you need to implement it? Just forward the requests to the machine > with the real driver. > >> Or do you want me >> to invent wheels and to recode everything in the library? > > Kernel code is GPLv2. You can use its code on a GPLv2 licensed library. I see. So if you think it is nice to get dvb-core, make a wrapper around to get it usable in userspace and maintain totally same functionality by myself then I say it is no go. If it looks for you like good idea I must disagree. Code duplication? Two maintaners? That is crazy idea man. > >> Of course >> I can be wrong, I'm no big kernel hacker. So please show me the >> way for it. BTW, even if you can find the way, then data copying >> from userspace to the kernel and back is also necessery. > > See libv4l, at v4l2-utils.git (at linuxtv.org). > >> I really >> don't see any advantage of you solution. > > And I can't see any advantage on yours ;) Putting something that belongs > to userspace into kernelspace just because it is easier to re-use the > existing code inside the kernel is not a good argument. It is only your POV that it should be in userspace. Creating additional code which not only enlarge code size by 2 but I think by 10 is really not good idea. And it get no advantage only disadvantages. > > Don't get me wrong but if you want to submit a code to be merged > on any existing software (being open source or not), you should be > prepared to defend your code and justify the need for it to the > other developers. Sure. I was prepared for technical disscussion, but was fully suprised that it was not happend (ok, to be correct, few guys are exception, like Andreas and few others. I really appreciate it). So, my question was still not answered: "Can be driver NACKed only because of worrying about possible misuse?" Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 01-12-2011 12:58, HoP wrote: Hi, let me ask you some details of your interesting idea (how to achieve the same functionality as with vtunerc driver): [...] The driver, as proposed, is not really a driver, as it doesn't support any hardware. The kernel driver would be used to just copy data from one userspace Please stop learning me what can be called driver and what nope. Your definition is nonsense and I don't want to follow you on it. application to the other. The same result could be obtained in userspace, by implementing a library. Such library could even use LD_PRELOAD to support binary only applications, like what libv4l does. In terms of performance, such library would probably perform better than a kernel driver, as there's no need to do context switching for each call, and no need to talk with a device (where kernel outperforms userspace). Also, depending on how such library is implemented, double buffering might be avoided. So, from architectural POV, this code should be written as an userspace library. BTW, alsa also came with the same results, years ago, as audio remote streaming is supported via userspace tools, like pulseaudio. Can you show me, how then can be reused most important part of dvb-core subsystem like tuning and demuxing? Why do you need to implement it? Just forward the requests to the machine with the real driver. Or do you want me to invent wheels and to recode everything in the library? Kernel code is GPLv2. You can use its code on a GPLv2 licensed library. Of course I can be wrong, I'm no big kernel hacker. So please show me the way for it. BTW, even if you can find the way, then data copying from userspace to the kernel and back is also necessery. See libv4l, at v4l2-utils.git (at linuxtv.org). I really don't see any advantage of you solution. And I can't see any advantage on yours ;) Putting something that belongs to userspace into kernelspace just because it is easier to re-use the existing code inside the kernel is not a good argument. Don't get me wrong but if you want to submit a code to be merged on any existing software (being open source or not), you should be prepared to defend your code and justify the need for it to the other developers. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi, let me ask you some details of your interesting idea (how to achieve the same functionality as with vtunerc driver): [...] > The driver, as proposed, is not really a driver, as it doesn't support any > hardware. The kernel driver would be used to just copy data from one > userspace Please stop learning me what can be called driver and what nope. Your definition is nonsense and I don't want to follow you on it. > application to the other. The same result could be obtained in userspace, > by implementing a library. Such library could even use LD_PRELOAD to support > binary only applications, like what libv4l does. In terms of performance, > such library would probably perform better than a kernel driver, as there's > no need to do context switching for each call, and no need to talk with a > device (where kernel outperforms userspace). Also, depending on how such > library > is implemented, double buffering might be avoided. > > So, from architectural POV, this code should be written as an userspace > library. > BTW, alsa also came with the same results, years ago, as audio remote > streaming is supported via userspace tools, like pulseaudio. Can you show me, how then can be reused most important part of dvb-core subsystem like tuning and demuxing? Or do you want me to invent wheels and to recode everything in the library? Of course I can be wrong, I'm no big kernel hacker. So please show me the way for it. BTW, even if you can find the way, then data copying from userspace to the kernel and back is also necessery. I really don't see any advantage of you solution. Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device
Hi > On Wed, 30 Nov 2011 22:38:33 +0100, HoP wrote: >> I have one big problem with it. I can even imagine that some "bad guys" >> could abuse virtual driver to use it for distribution close-source > drivers >> in the binary blobs. But is it that - worrying about bad boys abusing - >> the sufficient reason for such aggressive NACK which I did? > > I am not a LinuxTV developer so I am not in position to take a stand for > or against this. Ultimately though, either your driver is rejected or it is > accepted. This is not really a matter of being aggressive or not. It just > so happens that many Linux-DVB contributors feel the same way against that > class of driver. > > Also note the fear of GPL avoidance is not unique to Linux-DVB. If I am > not mistaken there is no user-space socket API back-end for the same > reasons. And there is also no _in-tree_ loopback V4L2 device driver in > kernel. Well, that is why I was asking again - in some parts there are similar drivers accepted and in another parts no. Really confusing to me. I'm not kernel hacker, so I didn't know about historical cases. Sorry. [...] >> I can't understand that because I see very similar drivers in kernel for >> ages (nbd, or even more similar is usbip) and seems they don't hamper to >> anybody. > > Sure. On That said, the Network Block Device, USB-IP and TUNTAP are not > really competing with real drivers because of their high perfomance impact, > so they are probably not the best examples to support your argument. uinput > and ALSA loopback would seem like better examples to me. Thanks for hints. It is no problem to use another arguments, if things get cleaner then :-) >> I would like to note that I don't want to start any flame-war, >> so very short answer would be enough for me. > > Did you try to implement this through CUSE? Then there should be no GPL > problems. Also then you do not need to convince anybody to take your driver > in the kernel. I did a very quick look on CUSE and if I understood it well, it was usable for drivers not need for cooperation of other kernel internal subsystems. But DVB driver usually use dvb-core subsystem (for tuning and for pid filtering/demuxing), so I don't see the way how to connect there. I think it is impossible. Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device
Hello, On Wed, 30 Nov 2011 22:38:33 +0100, HoP wrote: > I have one big problem with it. I can even imagine that some "bad guys" > could abuse virtual driver to use it for distribution close-source drivers > in the binary blobs. But is it that - worrying about bad boys abusing - > the sufficient reason for such aggressive NACK which I did? I am not a LinuxTV developer so I am not in position to take a stand for or against this. Ultimately though, either your driver is rejected or it is accepted. This is not really a matter of being aggressive or not. It just so happens that many Linux-DVB contributors feel the same way against that class of driver. Also note the fear of GPL avoidance is not unique to Linux-DVB. If I am not mistaken there is no user-space socket API back-end for the same reasons. And there is also no _in-tree_ loopback V4L2 device driver in kernel. > Then would be better to remove loadable module API fully from kernel. > Is it the right way? You seem to been misrepresenting things on purpose here, and this will never play in your favor. > Please confirm me that worrying about abusive act is enough to NACK > particular driver. Then I may be definitely understand I'm doing something > wrong and will stay (with such enemy driver) out of tree. > > I can't understand that because I see very similar drivers in kernel for > ages (nbd, or even more similar is usbip) and seems they don't hamper to > anybody. Sure. On That said, the Network Block Device, USB-IP and TUNTAP are not really competing with real drivers because of their high perfomance impact, so they are probably not the best examples to support your argument. uinput and ALSA loopback would seem like better examples to me. > I would like to note that I don't want to start any flame-war, > so very short answer would be enough for me. Did you try to implement this through CUSE? Then there should be no GPL problems. Also then you do not need to convince anybody to take your driver in the kernel. -- Rémi Denis-Courmont http://www.remlab.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Communication misunderstanding? (was: Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?)
(stripped LKML) On Thursday 01 December 2011 01:09:28 Andreas Oberritter wrote: > [..] > Regarding the kernellabs.com people[3] lobbying against your > contribution: > [..] KernelLabs is not a collections of politicians who want to change the world together whatever the costs. We are professional individuals in our decisions and views. I think it's better to limit public discussions in a professional technical environment to technical problems - saying that I would want to encourage you discuss with us off-list or in our blog what makes you generalize in such a way? -- Patrick Boettcher Kernel Labs Inc. http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 30-11-2011 22:09, Andreas Oberritter wrote: On 30.11.2011 22:38, HoP wrote: Hi folks. I need to warn you that my mail is a bit little longer then I would like to be.But I'm not able to ask my question without some background information. On June 19th, I was sending the driver to the Linux-media mailing list. Original announcement is there: http://www.spinics.net/lists/linux-media/msg34240.html One would say that the code describes very well what it does = adds virtual DVB device. To be more clear on it I have even done some small picture: http://www.nessiedvb.org/wiki/doku.php?id=vtuner_bigpicture I was hoping to get any feedback regarding code implementation. It was my first code for the kernel and I felt very well that some part can be done better or even simpler. What really surprised me badly was that when I read all 54 responses I have counted only two real technical answers!!! All rest were about POLITICAL issues - code was NACKed w/o any technical discussion. Because of fear of possible abusing of driver. I didn't know that there existed very big movement against such code in dvb-core subsystem before. I have one big problem with it. I can even imagine that some "bad guys" could abuse virtual driver to use it for distribution close-source drivers in the binary blobs. But is it that - worrying about bad boys abusing - the sufficient reason for such aggressive NACK which I did? Then would be better to remove loadable module API fully from kernel. Is it the right way? Please confirm me that worrying about abusive act is enough to NACK particular driver. Then I may be definitely understand I'm doing something wrong and will stay (with such enemy driver) out of tree. I can't understand that because I see very similar drivers in kernel for ages (nbd, or even more similar is usbip) and seems they don't hamper to anybody. I would like to note that I don't want to start any flame-war, so very short answer would be enough for me., Hello Honza, I still support the inclusion of your virtual DVB device driver, once the technical issues[1] are solved (design clean interface based on DVBv5 etc.). Mauro promised to consider it for inclusion then[2]. What I said on that time is that a virtual driver to run at the OS on a VM machine (kvm or xen) that would export the DVB devices that are available at the OS at the local host or on a remote host running the spice client could be an interesting contribution, and would fit into kernelspace. I'm not sure about such need nowadays, as very recent patches added on kvm are now allowing to use USB 2.0 video devices on it (I tested and used it a few days ago - it seems to be working at least with the devices I tested), and PCI passthrough is already there also. Yet, a DVB-optimized passthrough module there would likely perform better than just exporting the physical device to the VM. The driver, as proposed, is not really a driver, as it doesn't support any hardware. The kernel driver would be used to just copy data from one userspace application to the other. The same result could be obtained in userspace, by implementing a library. Such library could even use LD_PRELOAD to support binary only applications, like what libv4l does. In terms of performance, such library would probably perform better than a kernel driver, as there's no need to do context switching for each call, and no need to talk with a device (where kernel outperforms userspace). Also, depending on how such library is implemented, double buffering might be avoided. So, from architectural POV, this code should be written as an userspace library. BTW, alsa also came with the same results, years ago, as audio remote streaming is supported via userspace tools, like pulseaudio. A quick view at your code indicates that this clean-up hasn't happened yet, e.g. there are hacks to support DVB-S2 over DVBv3 which aren't necessary anymore with v5. Regarding the kernellabs.com people[3] lobbying against your contribution: Don't give up! If all attempts of merging your work through the media subsystem are failing, try convincing some major distributions to include your work. This would make their arguments meaningless. On the long run, good code is likely to win over politics. Regards, Andreas [1] http://www.spinics.net/lists/linux-media/msg34349.html [2] http://www.spinics.net/lists/linux-media/msg34352.html [3] http://www.kernellabs.com/blog/?page_id=6 [4] http://code.google.com/p/vtuner/source/browse/vtunerc_proxyfe.c?repo=linux-driver#177 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 30.11.2011 22:38, HoP wrote: > Hi folks. > > I need to warn you that my mail is a bit little longer then I would like > to be.But I'm not able to ask my question without some > background information. > > On June 19th, I was sending the driver to the Linux-media > mailing list. Original announcement is there: > > http://www.spinics.net/lists/linux-media/msg34240.html > > One would say that the code describes very well what it does = adds > virtual DVB device. To be more clear on it I have even done some > small picture: > > http://www.nessiedvb.org/wiki/doku.php?id=vtuner_bigpicture > > I was hoping to get any feedback regarding code implementation. > It was my first code for the kernel and I felt very well that some > part can be done better or even simpler. > > What really surprised me badly was that when I read all 54 responses > I have counted only two real technical answers!!! All rest were about > POLITICAL issues - code was NACKed w/o any technical discussion. > Because of fear of possible abusing of driver. > > I didn't know that there existed very big movement against such > code in dvb-core subsystem before. > > I have one big problem with it. I can even imagine that some "bad guys" > could abuse virtual driver to use it for distribution close-source drivers > in the binary blobs. But is it that - worrying about bad boys abusing - > the sufficient reason for such aggressive NACK which I did? Then would > be better to remove loadable module API fully from kernel. Is it the right > way? > > Please confirm me that worrying about abusive act is enough to NACK > particular driver. Then I may be definitely understand I'm doing something > wrong and will stay (with such enemy driver) out of tree. > > I can't understand that because I see very similar drivers in kernel for ages > (nbd, or even more similar is usbip) and seems they don't hamper to anybody. > > I would like to note that I don't want to start any flame-war, so very short > answer would be enough for me., Hello Honza, I still support the inclusion of your virtual DVB device driver, once the technical issues[1] are solved (design clean interface based on DVBv5 etc.). Mauro promised to consider it for inclusion then[2]. A quick view at your code indicates that this clean-up hasn't happened yet, e.g. there are hacks to support DVB-S2 over DVBv3 which aren't necessary anymore with v5. Regarding the kernellabs.com people[3] lobbying against your contribution: Don't give up! If all attempts of merging your work through the media subsystem are failing, try convincing some major distributions to include your work. This would make their arguments meaningless. On the long run, good code is likely to win over politics. Regards, Andreas [1] http://www.spinics.net/lists/linux-media/msg34349.html [2] http://www.spinics.net/lists/linux-media/msg34352.html [3] http://www.kernellabs.com/blog/?page_id=6 [4] http://code.google.com/p/vtuner/source/browse/vtunerc_proxyfe.c?repo=linux-driver#177 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Wed, Nov 30, 2011 at 4:38 PM, HoP wrote: > Hi folks. > > I need to warn you that my mail is a bit little longer then I would like > to be.But I'm not able to ask my question without some > background information. > > On June 19th, I was sending the driver to the Linux-media > mailing list. Original announcement is there: > > http://www.spinics.net/lists/linux-media/msg34240.html > > One would say that the code describes very well what it does = adds > virtual DVB device. To be more clear on it I have even done some > small picture: > > http://www.nessiedvb.org/wiki/doku.php?id=vtuner_bigpicture > > I was hoping to get any feedback regarding code implementation. > It was my first code for the kernel and I felt very well that some > part can be done better or even simpler. > > What really surprised me badly was that when I read all 54 responses > I have counted only two real technical answers!!! All rest were about > POLITICAL issues - code was NACKed w/o any technical discussion. > Because of fear of possible abusing of driver. > > I didn't know that there existed very big movement against such > code in dvb-core subsystem before. > > I have one big problem with it. I can even imagine that some "bad guys" > could abuse virtual driver to use it for distribution close-source drivers > in the binary blobs. But is it that - worrying about bad boys abusing - > the sufficient reason for such aggressive NACK which I did? Then would > be better to remove loadable module API fully from kernel. Is it the right > way? > > Please confirm me that worrying about abusive act is enough to NACK > particular driver. Then I may be definitely understand I'm doing something > wrong and will stay (with such enemy driver) out of tree. > > I can't understand that because I see very similar drivers in kernel for ages > (nbd, or even more similar is usbip) and seems they don't hamper to anybody. > > I would like to note that I don't want to start any flame-war, so very short > answer would be enough for me. > > Regards > > Honza > > PS: Please be so kind and CC the answer/comment to me, I'm > only on linux-media ML, not on linux-kernel ML. Thanks. > > BTW, if accidentally, somebody find it interesting and would like to > help me doing code review, there is the code hosted now: > http://code.google.com/p/vtuner/source/browse?repo=linux-driver Honza, I, for one, would love to see your virtual DVB device driver hosted in a repository for the purposes of experimentation and additional development. I can think of many, many good uses for such a virtual device driver. Unfortunately, however, all the device vendors also have uses for it. It a guarunteed fact that if a driver like that got merged into the kernel, any software company that previously sponsored open-source kernel development would opt instead for closed source userspace drivers that depend on a virtual DVB device. Please don't let that discourage you -- I think you should continue your work on this virtual DVB device driver, and I'd love to play with it myself, and possibly even contribute to it. ...but I will never support the merging of this into the kernel. I do not nack the existence of the driver -- I love the idea, and I encourage more development. I only nack it's merging into any open-source linux kernel. Please accept my answer with the greatest intentions for furthering the development of the open-source community. My opinion is only for the best intentions of continued contributions from companies such as Hauppauge and any others that have contributed thus far to v4l/dvb. Please, keep up the work. I repeat -- I would love to play with your work. Best regards, Mike Krufky -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 16:18, Rémi Denis-Courmont escreveu: > Le mercredi 22 juin 2011 15:17:27 Mauro Carvalho Chehab, vous avez écrit : >>> My very little opinion is that waving GPL is way to the hell. Nobody told >>> me why similar technologies, in different kernel parts are acceptable, >>> but not here. >> >> If you want to do the networking code at userspace, why do you need a >> kernel driver after all? > > Are you seriously asking why people write tunneling drivers in user-space? Or > why they want to use the kernel-space socket API and protocol stack? > >> The proper solution is to write an userspace >> library for that, and either enclose such library inside the applications, >> or use LD_PRELOAD to bind the library to handle the open/close/ioctl glibc >> calls. libv4l does that. As it proofed to be a good library, now almost >> all V4L applications are using it. > > No. Set aside the problem of licensing, the correct way is to reuse existing > code, which means the layer-3/4 stacks and the socket API in net/*. That > avoids duplicating efforts (and bugs) and allows socket API apps to run > unchanged and without brittle hacks like LD_PRELOAD. > > And indeed, that's what the Linux ecosystem does, thanks to the tuntap > network > device driver. Rémi, Using the Kernel network layer is the right thing to do, but you don't need to add a new driver for it: it is already there. All that userspace needs to do is to use glibc socket's support. It could make sense to have some sort of virtualization driver that would allow passing DVB API calls via, for example, the network socket API, to allow accessing a physical DVB driver (or a remote machine DVB driver)from a VM machine. That was my original understanding. Instead, the proposal is wrapper, that will be a sort of kernelspace implementation for "LD_PRELOAD" that just returns the DVB commands back to some other application in userspace. The real code to transmit DVB commands will be in userspace. Technically speaking, this is a hack. If I would code something like that, I would write it as a library with some functions like: connect_to_dvb() get_dvb_properties() get_frontend_parameters() set_frontend_parameters() get_dvb_ts() And write a few patches for the userspace applications I would care. If I wanted to provide transparent access to it, I would simply implement a LD_PRELOAD schema, in order to help the new library deployment. With such approach, at the initial stages (the worse case, e. g. using LD_PRELOAD), it will be equivalent to have a kernel wrapper code, but, at long term, it will allow important optimizations, like avoiding the need of copying data from/to the wrapper, supporting the extra delays introducing by the network and allowing the applications to implement themselves the dialog windows to control the network properties. Thanks, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
Le mercredi 22 juin 2011 15:17:27 Mauro Carvalho Chehab, vous avez écrit : > > My very little opinion is that waving GPL is way to the hell. Nobody told > > me why similar technologies, in different kernel parts are acceptable, > > but not here. > > If you want to do the networking code at userspace, why do you need a > kernel driver after all? Are you seriously asking why people write tunneling drivers in user-space? Or why they want to use the kernel-space socket API and protocol stack? > The proper solution is to write an userspace > library for that, and either enclose such library inside the applications, > or use LD_PRELOAD to bind the library to handle the open/close/ioctl glibc > calls. libv4l does that. As it proofed to be a good library, now almost > all V4L applications are using it. No. Set aside the problem of licensing, the correct way is to reuse existing code, which means the layer-3/4 stacks and the socket API in net/*. That avoids duplicating efforts (and bugs) and allows socket API apps to run unchanged and without brittle hacks like LD_PRELOAD. And indeed, that's what the Linux ecosystem does, thanks to the tuntap network device driver. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
On Sat, Jun 18, 2011 at 8:10 PM, HoP wrote: > Hi, > > get inspired by (unfortunately close-source) solution on stb > Dreambox 800 I have made my own implementation > of virtual DVB device, based on the same device API. > > In conjunction with "Dreamtuner" userland project > [http://code.google.com/p/dreamtuner/] by Ronald Mieslinger > user can create virtual DVB device on client side and connect it > to the server. When connected, user is able to use any Linux DVB API > compatible application on client side (like VDR, MeTV, MythTV, etc) > without any need of code modification. As server can be used any > Linux DVB API compatible device. I can think of many interesting uses for a solution like this. It's great that such a driver exists and that people can use it now to create interesting do-it-yourself projects, however, I do not believe this should ever be merged into the kernel. If this solution were merged into the kernel, there would be no reason for companies like Hauppauge to ever again contribute any open source drivers. Once it's possible to deliver a closed source driver to the masses, that's what vendors will do -- there will no longer be any motivation to continue working in open source. Some may like that idea, but I feel this will destroy the foundation that we've been building for years. I repeat, the solution itself has some potential, and I see nothing wrong with this existing and being available to users in source code form, but it should never be merged into a kernel to be shipped directly to end-users. This can create a horrible president that would truly result in the prevention of open source driver contributions from silicon vendors and hardware manufacturers. Regards, Michael Krufky LinuxTV developer / Hauppauge Digital -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
>> This is not a political issue. It is a licensing issue. If you want to use >> someone's else code, you need to accept the licensing terms that the >> developers >> are giving you, by either paying the price for the code usage (on closed >> source >> licensing models), or by accepting the license when using an open-sourced >> code. Mauro, My comments for your review: I've spoken on this topic many times, it's bad news for the LinuxTV eco-system and it will eventually lead to binary only drivers that ultimately diminishes all of the good work that me any my fellow developers have poured into Linux over the last 5-10 years. I repeat my message from 2 years ago when the subject was raised: and this is (paraphrase) "I can say with great certainty that if we allow API's that permit closed source drivers then silicon vendors and board manufacturers will take advantage of that, they will only delivery (at best) closed source drivers". If closed source drivers is what the community wants then this is a way to achieve this. I don't want to see user-space drivers happen through LinuxDVB or V4L2 API's. I politely and respectfully nack this idea. Best, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
On 06/22/2011 05:19 PM, Mauro Carvalho Chehab wrote: > Em 22-06-2011 11:24, Andreas Oberritter escreveu: >> On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote: >>> Em 22-06-2011 10:13, Andreas Oberritter escreveu: On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: > Em 22-06-2011 09:37, HoP escreveu: >> 2011/6/22 Mauro Carvalho Chehab : >>> Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab : >> [...] > If people have different understandings, then we'll likely need to > ask some > support from Open source lawyers about this subject. My very little opinion is that waving GPL is way to the hell. Nobody told me why similar technologies, in different kernel parts are acceptable, but not here. >>> >>> If you want to do the networking code at userspace, why do you need a >>> kernel >>> driver after all? The proper solution is to write an userspace library >>> for that, >>> and either enclose such library inside the applications, or use >>> LD_PRELOAD to >>> bind the library to handle the open/close/ioctl glibc calls. libv4l >>> does that. >>> As it proofed to be a good library, now almost all V4L applications are >>> using >>> it. >> >> LD_PELOAD is out of bussiness for normal work. It is technique for >> development >> and/or debugging. > > Well, libv4l successfully uses LD_PRELOAD in order to support all > applications > that weren't ported to it yet. It offers two ways: > 1) you can use it as a normal library; > 2) you can use it with LD_PRELOAD. > > >> Library would be possible, but then you kill main advantage >> - totally independece of changes inside userland DVB applications. > > Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same > syntax of > glibc open, ioctl, ..., the efforts to migrate an userspace application > to use it > is to just run: > sed s,open,dvb_open,g > sed s,ioctl,dvb_ioctl,g > > > The library and the application will be completely independent. How do you transparently set up the network parameters? By using environment variables? How do you pass existing sockets to the library? How do you intercept an open() that won't ever happen, because no virtual device to be opened exists? >>> >>> Sorry, but I failed to see at the vtunerc driver anything network-related. >> >> Of course it doesn't. You're the one who proposed to put networking into >> the driver. I however fail to see how you imagined to add remote tuner >> support to any existing application by using LD_PRELOAD. > > If you take a look at libv4l, it hooks calls to open/close/ioctl/read/write > glibc > calls. So, when an userspace application calls "open", it will run the library > code, and not glibc open function. So, it is completely transparent to the > userspace application. Again, please answer this question, how do you plan to intercept an open() call for a character device that *doesn't exist*, because it's on a remote system? That open() will never happen. LD_PRELOAD may have worked well for whatever was needed for libv4l, but that's obviously a different thing. >>> Also, the picture shows that it is just acting as a proxy to an userspace >>> code >>> that it is actually handling the network conversion. The complete solution >>> seems to have a kernel driver and an userspace client/daemon. >> >> Right. >> >>> Technically, doing such proxy in kernel is not a good idea, due to several >>> reasons: >>> >>> 1) The proxy code and the userspace network client will need to be tightly >>> coupled: >>> if you add a new feature at the proxy, the same feature will need to be >>> supported by >>> the userspace daemon; >> >> Just like anything else DVB related inside the kernel. > > Yes. > >> Adding a new feature to the proxy would mean that a new feature got >> added to the frontend API, so a new kernel would be required anyway. >> >>> 2) Data will need to be using copy_from_user/copy_to_user for every data >>> access; >> >> Also, just like anything else DVB related inside the kernel. > > Yes, but if you do it on userspace, you don't need to do double buffering. > With a proxy, the same data will need to be passed 3 times from/to > kernelspace: > 2 times at vtunerc, and 1 time to the network driver. If implemented on > userspace, > all it needed is to pass the data to the network driver, reducing latency. > > Also, newer functions can be added on userspace in order to optimize > applications > that will use it as a library, like providing functions that combine DVB and > network commands altogether. > >> No one would notice some frontend ioctl parameters being copied twice. >> We're talking about a few bytes. > > If the intention is to limit it to just frontend ioctl's, you're right: the > only di
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 11:24, Andreas Oberritter escreveu: > On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote: >> Em 22-06-2011 10:13, Andreas Oberritter escreveu: >>> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: Em 22-06-2011 09:37, HoP escreveu: > 2011/6/22 Mauro Carvalho Chehab : >> Em 21-06-2011 14:38, HoP escreveu: >>> 2011/6/21 Mauro Carvalho Chehab : > [...] If people have different understandings, then we'll likely need to ask some support from Open source lawyers about this subject. >>> >>> My very little opinion is that waving GPL is way to the hell. Nobody >>> told me >>> why similar technologies, in different kernel parts are acceptable, >>> but not here. >> >> If you want to do the networking code at userspace, why do you need a >> kernel >> driver after all? The proper solution is to write an userspace library >> for that, >> and either enclose such library inside the applications, or use >> LD_PRELOAD to >> bind the library to handle the open/close/ioctl glibc calls. libv4l does >> that. >> As it proofed to be a good library, now almost all V4L applications are >> using >> it. > > LD_PELOAD is out of bussiness for normal work. It is technique for > development > and/or debugging. Well, libv4l successfully uses LD_PRELOAD in order to support all applications that weren't ported to it yet. It offers two ways: 1) you can use it as a normal library; 2) you can use it with LD_PRELOAD. > Library would be possible, but then you kill main advantage > - totally independece of changes inside userland DVB applications. Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same syntax of glibc open, ioctl, ..., the efforts to migrate an userspace application to use it is to just run: sed s,open,dvb_open,g sed s,ioctl,dvb_ioctl,g The library and the application will be completely independent. >>> >>> How do you transparently set up the network parameters? By using >>> environment variables? How do you pass existing sockets to the library? >>> How do you intercept an open() that won't ever happen, because no >>> virtual device to be opened exists? >> >> Sorry, but I failed to see at the vtunerc driver anything network-related. > > Of course it doesn't. You're the one who proposed to put networking into > the driver. I however fail to see how you imagined to add remote tuner > support to any existing application by using LD_PRELOAD. If you take a look at libv4l, it hooks calls to open/close/ioctl/read/write glibc calls. So, when an userspace application calls "open", it will run the library code, and not glibc open function. So, it is completely transparent to the userspace application. >> Also, the picture shows that it is just acting as a proxy to an userspace >> code >> that it is actually handling the network conversion. The complete solution >> seems to have a kernel driver and an userspace client/daemon. > > Right. > >> Technically, doing such proxy in kernel is not a good idea, due to several >> reasons: >> >> 1) The proxy code and the userspace network client will need to be tightly >> coupled: >> if you add a new feature at the proxy, the same feature will need to be >> supported by >> the userspace daemon; > > Just like anything else DVB related inside the kernel. Yes. > Adding a new feature to the proxy would mean that a new feature got > added to the frontend API, so a new kernel would be required anyway. > >> 2) Data will need to be using copy_from_user/copy_to_user for every data >> access; > > Also, just like anything else DVB related inside the kernel. Yes, but if you do it on userspace, you don't need to do double buffering. With a proxy, the same data will need to be passed 3 times from/to kernelspace: 2 times at vtunerc, and 1 time to the network driver. If implemented on userspace, all it needed is to pass the data to the network driver, reducing latency. Also, newer functions can be added on userspace in order to optimize applications that will use it as a library, like providing functions that combine DVB and network commands altogether. > No one would notice some frontend ioctl parameters being copied twice. > We're talking about a few bytes. If the intention is to limit it to just frontend ioctl's, you're right: the only difference is that latency will be a little higher, probably unnoticed (yet, introduced for not a good reason). But, if the intention is to also provide remote streaming, then the volume of data copied tree times will be noticeable, especially if the stream is in HD and/or if support for full-featured DVB cards is added later. > Passing the remote TS to the kernel is completely *optional*, and only > required if you want to use the kernel's demux or the underlying > hardware's fi
Re: [RFC] vtunerc - virtual DVB device driver
On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote: > Em 22-06-2011 10:13, Andreas Oberritter escreveu: >> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: >>> Em 22-06-2011 09:37, HoP escreveu: 2011/6/22 Mauro Carvalho Chehab : > Em 21-06-2011 14:38, HoP escreveu: >> 2011/6/21 Mauro Carvalho Chehab : [...] >>> If people have different understandings, then we'll likely need to ask >>> some >>> support from Open source lawyers about this subject. >> >> My very little opinion is that waving GPL is way to the hell. Nobody >> told me >> why similar technologies, in different kernel parts are acceptable, >> but not here. > > If you want to do the networking code at userspace, why do you need a > kernel > driver after all? The proper solution is to write an userspace library > for that, > and either enclose such library inside the applications, or use > LD_PRELOAD to > bind the library to handle the open/close/ioctl glibc calls. libv4l does > that. > As it proofed to be a good library, now almost all V4L applications are > using > it. LD_PELOAD is out of bussiness for normal work. It is technique for development and/or debugging. >>> >>> Well, libv4l successfully uses LD_PRELOAD in order to support all >>> applications >>> that weren't ported to it yet. It offers two ways: >>> 1) you can use it as a normal library; >>> 2) you can use it with LD_PRELOAD. >>> >>> Library would be possible, but then you kill main advantage - totally independece of changes inside userland DVB applications. >>> >>> Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same >>> syntax of >>> glibc open, ioctl, ..., the efforts to migrate an userspace application to >>> use it >>> is to just run: >>> sed s,open,dvb_open,g >>> sed s,ioctl,dvb_ioctl,g >>> >>> >>> The library and the application will be completely independent. >> >> How do you transparently set up the network parameters? By using >> environment variables? How do you pass existing sockets to the library? >> How do you intercept an open() that won't ever happen, because no >> virtual device to be opened exists? > > Sorry, but I failed to see at the vtunerc driver anything network-related. Of course it doesn't. You're the one who proposed to put networking into the driver. I however fail to see how you imagined to add remote tuner support to any existing application by using LD_PRELOAD. > Also, the picture shows that it is just acting as a proxy to an userspace code > that it is actually handling the network conversion. The complete solution > seems to have a kernel driver and an userspace client/daemon. Right. > Technically, doing such proxy in kernel is not a good idea, due to several > reasons: > > 1) The proxy code and the userspace network client will need to be tightly > coupled: > if you add a new feature at the proxy, the same feature will need to be > supported by > the userspace daemon; Just like anything else DVB related inside the kernel. Adding a new feature to the proxy would mean that a new feature got added to the frontend API, so a new kernel would be required anyway. > 2) Data will need to be using copy_from_user/copy_to_user for every data > access; Also, just like anything else DVB related inside the kernel. No one would notice some frontend ioctl parameters being copied twice. We're talking about a few bytes. Passing the remote TS to the kernel is completely *optional*, and only required if you want to use the kernel's demux or the underlying hardware's filtering and decoding features. However, the TS even gets filtered before being transferred over the network. So again, even if used though being optional, this is not a big data rate. > 3) There's no good reason to write such code inside kernelspace. > > On a library based approach, what you'll have, instead is a library. The same > userspace client/daemon will be needed. However, as both can be shipped > together > (the library proxy code and the userspace client/daemon), there are several > advantages, like: > > 1) The library and the userspace client will be in sync: there's no need to > check > for version differences at the api, or providing any sort of backport support; Breaking the ABI of libraries isn't much better than breaking the ABI of kernel interfaces. A library may have many users, more than "the userspace client" you're talking about. > 2) There's no need to recompile the kernel when someone wants to use the > proxy; You could of course build it as a module, without the need to recompile the kernel. > 3) The userspace won't be bound to the Kernel release schedule: When the code > is > stable enough, both libraries and userspace can be released at the same time. For the same reason one could argue that putting device drivers into userspace would have the same benefits. Well, the original proposal
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 11:03, HoP escreveu: > 2011/6/22 Mauro Carvalho Chehab : >> Em 22-06-2011 10:13, Andreas Oberritter escreveu: >>> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: Em 22-06-2011 09:37, HoP escreveu: > 2011/6/22 Mauro Carvalho Chehab : >> Em 21-06-2011 14:38, HoP escreveu: >>> 2011/6/21 Mauro Carvalho Chehab : Em 21-06-2011 12:09, Andreas Oberritter escreveu: > On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >> Em 21-06-2011 11:15, Andreas Oberritter escreveu: >>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter wrote: > Mauro and Devin, I think you're missing the point. This is not > about > creating drivers in userspace. This is not about open or closed > source. > The "vtuner" interface, as implemented for the Dreambox, is used > to > access remote tuners: Put x tuners into y boxes and access them > from > another box as if they were local. It's used in conjunction with > further > software to receive the transport stream over a network > connection. > Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. > You don't need it in order to create closed source drivers. You > can > already create closed kernel drivers now. Also, you can create > tuner > drivers in userspace using the i2c-dev interface. If you like to > connect > a userspace driver to a DVB API device node, you can distribute a > small > (open or closed) wrapper with it. So what are you arguing about? > Everything you're feared of can already be done since virtually > forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === "Devin, we need to support tuner X under Linux." "Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device" "But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor)." "Ok. Well, what is the licensing for that code? Is it GPL compatible?" "Not currently. So can we just make our driver closed source?" "Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch." "Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply". "Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core." "Oh, ok
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/22 Mauro Carvalho Chehab : > Em 22-06-2011 10:13, Andreas Oberritter escreveu: >> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: >>> Em 22-06-2011 09:37, HoP escreveu: 2011/6/22 Mauro Carvalho Chehab : > Em 21-06-2011 14:38, HoP escreveu: >> 2011/6/21 Mauro Carvalho Chehab : >>> Em 21-06-2011 12:09, Andreas Oberritter escreveu: On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: > Em 21-06-2011 11:15, Andreas Oberritter escreveu: >> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: >>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter >>> wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The "vtuner" interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. >>> >>> I'm not missing the point at all. I realize exactly what Honza is >>> trying to accomplish (and from a purely technical standpoint, it's >>> not >>> a bad approach) - but I'm talking about the effects of such a driver >>> being introduced which changes the kernel/userland licensing >>> boundary >>> and has very real implications with how the in-kernel code is >>> accessed. >>> You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. >>> >>> I disagree. There is currently no API which allows applications to >>> issue tuning requests into the DVB core, and have those requests >>> proxied back out to userland where an application can then use >>> i2c-dev >>> to tune the actual device. Meaning if somebody wants to write a >>> closed source userland application which controls the tuner, he/she >>> can do that (while not conforming to the DVB API). But if if he >>> wants >>> to reuse the GPL licensed DVB core, he has to replace the entire DVB >>> core. >>> >>> The introduction of this patch makes it trivial for a third party to >>> provide closed-source userland support for tuners while reusing all >>> the existing GPL driver code that makes up the framework. >>> >>> I used to work for a vendor that makes tuners, and they do a bunch >>> of >>> Linux work. And that work has resulted in a bunch of open source >>> drivers. I can tell you though that *every* conversation I've had >>> regarding a new driver goes something like this: >>> >>> === >>> "Devin, we need to support tuner X under Linux." >>> >>> "Great! I'll be happy to write a new GPL driver for the >>> tuner/demodulator/whatever for that device" >>> >>> "But to save time/money, we just want to reuse the Windows driver >>> code >>> (or reference code from the vendor)." >>> >>> "Ok. Well, what is the licensing for that code? Is it GPL >>> compatible?" >>> >>> "Not currently. So can we just make our driver closed source?" >>> >>> "Well, you can't reuse any of the existing DVB core functionality or >>> any of the other GPL drivers (tuners, bridges, demods), so you would >>> have rewrite all that from scratch." >>> >>> "Oh, that would be a ton of work. Can we maybe write some userland >>> stuff that controls the demodulator which we can keep closed source? >>> Since it's not in the kernel, the GPL won't apply". >>> >>> "Well, you can't really do that because there is no way for the DVB >>> core to call back out to userland when the application makes the >>> tuning request to the DVB core." >>> >>> "Oh, ok then. I guess we'll have to talk to the vendor and get them >>> to give us the reference driver code under the GPL." >>> === >>> >>> I can tell you without a doubt that if this driver were present in >>> the >>> kernel, tha
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 10:13, Andreas Oberritter escreveu: > On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: >> Em 22-06-2011 09:37, HoP escreveu: >>> 2011/6/22 Mauro Carvalho Chehab : Em 21-06-2011 14:38, HoP escreveu: > 2011/6/21 Mauro Carvalho Chehab : >> Em 21-06-2011 12:09, Andreas Oberritter escreveu: >>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 11:15, Andreas Oberritter escreveu: > On 06/21/2011 03:44 PM, Devin Heitmueller wrote: >> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter >> wrote: >>> Mauro and Devin, I think you're missing the point. This is not about >>> creating drivers in userspace. This is not about open or closed >>> source. >>> The "vtuner" interface, as implemented for the Dreambox, is used to >>> access remote tuners: Put x tuners into y boxes and access them from >>> another box as if they were local. It's used in conjunction with >>> further >>> software to receive the transport stream over a network connection. >>> Honza's code does the same thing. >> >> I'm not missing the point at all. I realize exactly what Honza is >> trying to accomplish (and from a purely technical standpoint, it's >> not >> a bad approach) - but I'm talking about the effects of such a driver >> being introduced which changes the kernel/userland licensing boundary >> and has very real implications with how the in-kernel code is >> accessed. >> >>> You don't need it in order to create closed source drivers. You can >>> already create closed kernel drivers now. Also, you can create tuner >>> drivers in userspace using the i2c-dev interface. If you like to >>> connect >>> a userspace driver to a DVB API device node, you can distribute a >>> small >>> (open or closed) wrapper with it. So what are you arguing about? >>> Everything you're feared of can already be done since virtually >>> forever. >> >> I disagree. There is currently no API which allows applications to >> issue tuning requests into the DVB core, and have those requests >> proxied back out to userland where an application can then use >> i2c-dev >> to tune the actual device. Meaning if somebody wants to write a >> closed source userland application which controls the tuner, he/she >> can do that (while not conforming to the DVB API). But if if he >> wants >> to reuse the GPL licensed DVB core, he has to replace the entire DVB >> core. >> >> The introduction of this patch makes it trivial for a third party to >> provide closed-source userland support for tuners while reusing all >> the existing GPL driver code that makes up the framework. >> >> I used to work for a vendor that makes tuners, and they do a bunch of >> Linux work. And that work has resulted in a bunch of open source >> drivers. I can tell you though that *every* conversation I've had >> regarding a new driver goes something like this: >> >> === >> "Devin, we need to support tuner X under Linux." >> >> "Great! I'll be happy to write a new GPL driver for the >> tuner/demodulator/whatever for that device" >> >> "But to save time/money, we just want to reuse the Windows driver >> code >> (or reference code from the vendor)." >> >> "Ok. Well, what is the licensing for that code? Is it GPL >> compatible?" >> >> "Not currently. So can we just make our driver closed source?" >> >> "Well, you can't reuse any of the existing DVB core functionality or >> any of the other GPL drivers (tuners, bridges, demods), so you would >> have rewrite all that from scratch." >> >> "Oh, that would be a ton of work. Can we maybe write some userland >> stuff that controls the demodulator which we can keep closed source? >> Since it's not in the kernel, the GPL won't apply". >> >> "Well, you can't really do that because there is no way for the DVB >> core to call back out to userland when the application makes the >> tuning request to the DVB core." >> >> "Oh, ok then. I guess we'll have to talk to the vendor and get them >> to give us the reference driver code under the GPL." >> === >> >> I can tell you without a doubt that if this driver were present in >> the >> kernel, that going forward that vendor would have *zero* interest in >> doing any GPL driver work. Why would they? Why give away the code >> which could potentially help their competitors if
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/22 Mauro Carvalho Chehab : > Em 22-06-2011 09:30, Andreas Oberritter escreveu: >> On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote: >>> Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab : > Em 21-06-2011 12:09, Andreas Oberritter escreveu: >> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >>> Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: > On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter > wrote: >> Mauro and Devin, I think you're missing the point. This is not about >> creating drivers in userspace. This is not about open or closed >> source. >> The "vtuner" interface, as implemented for the Dreambox, is used to >> access remote tuners: Put x tuners into y boxes and access them from >> another box as if they were local. It's used in conjunction with >> further >> software to receive the transport stream over a network connection. >> Honza's code does the same thing. > > I'm not missing the point at all. I realize exactly what Honza is > trying to accomplish (and from a purely technical standpoint, it's not > a bad approach) - but I'm talking about the effects of such a driver > being introduced which changes the kernel/userland licensing boundary > and has very real implications with how the in-kernel code is > accessed. > >> You don't need it in order to create closed source drivers. You can >> already create closed kernel drivers now. Also, you can create tuner >> drivers in userspace using the i2c-dev interface. If you like to >> connect >> a userspace driver to a DVB API device node, you can distribute a >> small >> (open or closed) wrapper with it. So what are you arguing about? >> Everything you're feared of can already be done since virtually >> forever. > > I disagree. There is currently no API which allows applications to > issue tuning requests into the DVB core, and have those requests > proxied back out to userland where an application can then use i2c-dev > to tune the actual device. Meaning if somebody wants to write a > closed source userland application which controls the tuner, he/she > can do that (while not conforming to the DVB API). But if if he wants > to reuse the GPL licensed DVB core, he has to replace the entire DVB > core. > > The introduction of this patch makes it trivial for a third party to > provide closed-source userland support for tuners while reusing all > the existing GPL driver code that makes up the framework. > > I used to work for a vendor that makes tuners, and they do a bunch of > Linux work. And that work has resulted in a bunch of open source > drivers. I can tell you though that *every* conversation I've had > regarding a new driver goes something like this: > > === > "Devin, we need to support tuner X under Linux." > > "Great! I'll be happy to write a new GPL driver for the > tuner/demodulator/whatever for that device" > > "But to save time/money, we just want to reuse the Windows driver code > (or reference code from the vendor)." > > "Ok. Well, what is the licensing for that code? Is it GPL > compatible?" > > "Not currently. So can we just make our driver closed source?" > > "Well, you can't reuse any of the existing DVB core functionality or > any of the other GPL drivers (tuners, bridges, demods), so you would > have rewrite all that from scratch." > > "Oh, that would be a ton of work. Can we maybe write some userland > stuff that controls the demodulator which we can keep closed source? > Since it's not in the kernel, the GPL won't apply". > > "Well, you can't really do that because there is no way for the DVB > core to call back out to userland when the application makes the > tuning request to the DVB core." > > "Oh, ok then. I guess we'll have to talk to the vendor and get them > to give us the reference driver code under the GPL." > === > > I can tell you without a doubt that if this driver were present in the > kernel, that going forward that vendor would have *zero* interest in > doing any GPL driver work. Why would they? Why give away the code > which could potentially help their competitors if they can keep it > safe and protected while still being able to reuse everybody else's > contributions? > > Companies don't contribute GPL code out of "g
Re: [RFC] vtunerc - virtual DVB device driver
On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: > Em 22-06-2011 09:37, HoP escreveu: >> 2011/6/22 Mauro Carvalho Chehab : >>> Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab : > Em 21-06-2011 12:09, Andreas Oberritter escreveu: >> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >>> Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: > On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter > wrote: >> Mauro and Devin, I think you're missing the point. This is not about >> creating drivers in userspace. This is not about open or closed >> source. >> The "vtuner" interface, as implemented for the Dreambox, is used to >> access remote tuners: Put x tuners into y boxes and access them from >> another box as if they were local. It's used in conjunction with >> further >> software to receive the transport stream over a network connection. >> Honza's code does the same thing. > > I'm not missing the point at all. I realize exactly what Honza is > trying to accomplish (and from a purely technical standpoint, it's not > a bad approach) - but I'm talking about the effects of such a driver > being introduced which changes the kernel/userland licensing boundary > and has very real implications with how the in-kernel code is > accessed. > >> You don't need it in order to create closed source drivers. You can >> already create closed kernel drivers now. Also, you can create tuner >> drivers in userspace using the i2c-dev interface. If you like to >> connect >> a userspace driver to a DVB API device node, you can distribute a >> small >> (open or closed) wrapper with it. So what are you arguing about? >> Everything you're feared of can already be done since virtually >> forever. > > I disagree. There is currently no API which allows applications to > issue tuning requests into the DVB core, and have those requests > proxied back out to userland where an application can then use i2c-dev > to tune the actual device. Meaning if somebody wants to write a > closed source userland application which controls the tuner, he/she > can do that (while not conforming to the DVB API). But if if he wants > to reuse the GPL licensed DVB core, he has to replace the entire DVB > core. > > The introduction of this patch makes it trivial for a third party to > provide closed-source userland support for tuners while reusing all > the existing GPL driver code that makes up the framework. > > I used to work for a vendor that makes tuners, and they do a bunch of > Linux work. And that work has resulted in a bunch of open source > drivers. I can tell you though that *every* conversation I've had > regarding a new driver goes something like this: > > === > "Devin, we need to support tuner X under Linux." > > "Great! I'll be happy to write a new GPL driver for the > tuner/demodulator/whatever for that device" > > "But to save time/money, we just want to reuse the Windows driver code > (or reference code from the vendor)." > > "Ok. Well, what is the licensing for that code? Is it GPL > compatible?" > > "Not currently. So can we just make our driver closed source?" > > "Well, you can't reuse any of the existing DVB core functionality or > any of the other GPL drivers (tuners, bridges, demods), so you would > have rewrite all that from scratch." > > "Oh, that would be a ton of work. Can we maybe write some userland > stuff that controls the demodulator which we can keep closed source? > Since it's not in the kernel, the GPL won't apply". > > "Well, you can't really do that because there is no way for the DVB > core to call back out to userland when the application makes the > tuning request to the DVB core." > > "Oh, ok then. I guess we'll have to talk to the vendor and get them > to give us the reference driver code under the GPL." > === > > I can tell you without a doubt that if this driver were present in the > kernel, that going forward that vendor would have *zero* interest in > doing any GPL driver work. Why would they? Why give away the code > which could potentially help their competitors if they can keep it > safe and protected while still being able to reuse everybody else's > contributions? > > Companies don't contribute GPL code out of "good will". The
Re: [RFC] vtunerc - virtual DVB device driver
On 06/22/2011 02:55 PM, Mauro Carvalho Chehab wrote: > Em 22-06-2011 09:30, Andreas Oberritter escreveu: >> On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote: >>> Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab : > Em 21-06-2011 12:09, Andreas Oberritter escreveu: >> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >>> Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: > On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter > wrote: >> Mauro and Devin, I think you're missing the point. This is not about >> creating drivers in userspace. This is not about open or closed >> source. >> The "vtuner" interface, as implemented for the Dreambox, is used to >> access remote tuners: Put x tuners into y boxes and access them from >> another box as if they were local. It's used in conjunction with >> further >> software to receive the transport stream over a network connection. >> Honza's code does the same thing. > > I'm not missing the point at all. I realize exactly what Honza is > trying to accomplish (and from a purely technical standpoint, it's not > a bad approach) - but I'm talking about the effects of such a driver > being introduced which changes the kernel/userland licensing boundary > and has very real implications with how the in-kernel code is > accessed. > >> You don't need it in order to create closed source drivers. You can >> already create closed kernel drivers now. Also, you can create tuner >> drivers in userspace using the i2c-dev interface. If you like to >> connect >> a userspace driver to a DVB API device node, you can distribute a >> small >> (open or closed) wrapper with it. So what are you arguing about? >> Everything you're feared of can already be done since virtually >> forever. > > I disagree. There is currently no API which allows applications to > issue tuning requests into the DVB core, and have those requests > proxied back out to userland where an application can then use i2c-dev > to tune the actual device. Meaning if somebody wants to write a > closed source userland application which controls the tuner, he/she > can do that (while not conforming to the DVB API). But if if he wants > to reuse the GPL licensed DVB core, he has to replace the entire DVB > core. > > The introduction of this patch makes it trivial for a third party to > provide closed-source userland support for tuners while reusing all > the existing GPL driver code that makes up the framework. > > I used to work for a vendor that makes tuners, and they do a bunch of > Linux work. And that work has resulted in a bunch of open source > drivers. I can tell you though that *every* conversation I've had > regarding a new driver goes something like this: > > === > "Devin, we need to support tuner X under Linux." > > "Great! I'll be happy to write a new GPL driver for the > tuner/demodulator/whatever for that device" > > "But to save time/money, we just want to reuse the Windows driver code > (or reference code from the vendor)." > > "Ok. Well, what is the licensing for that code? Is it GPL > compatible?" > > "Not currently. So can we just make our driver closed source?" > > "Well, you can't reuse any of the existing DVB core functionality or > any of the other GPL drivers (tuners, bridges, demods), so you would > have rewrite all that from scratch." > > "Oh, that would be a ton of work. Can we maybe write some userland > stuff that controls the demodulator which we can keep closed source? > Since it's not in the kernel, the GPL won't apply". > > "Well, you can't really do that because there is no way for the DVB > core to call back out to userland when the application makes the > tuning request to the DVB core." > > "Oh, ok then. I guess we'll have to talk to the vendor and get them > to give us the reference driver code under the GPL." > === > > I can tell you without a doubt that if this driver were present in the > kernel, that going forward that vendor would have *zero* interest in > doing any GPL driver work. Why would they? Why give away the code > which could potentially help their competitors if they can keep it > safe and protected while still being able to reuse everybody else's > contributions? > > Companies don't contribute
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 09:37, HoP escreveu: > 2011/6/22 Mauro Carvalho Chehab : >> Em 21-06-2011 14:38, HoP escreveu: >>> 2011/6/21 Mauro Carvalho Chehab : Em 21-06-2011 12:09, Andreas Oberritter escreveu: > On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >> Em 21-06-2011 11:15, Andreas Oberritter escreveu: >>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter wrote: > Mauro and Devin, I think you're missing the point. This is not about > creating drivers in userspace. This is not about open or closed > source. > The "vtuner" interface, as implemented for the Dreambox, is used to > access remote tuners: Put x tuners into y boxes and access them from > another box as if they were local. It's used in conjunction with > further > software to receive the transport stream over a network connection. > Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. > You don't need it in order to create closed source drivers. You can > already create closed kernel drivers now. Also, you can create tuner > drivers in userspace using the i2c-dev interface. If you like to > connect > a userspace driver to a DVB API device node, you can distribute a > small > (open or closed) wrapper with it. So what are you arguing about? > Everything you're feared of can already be done since virtually > forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === "Devin, we need to support tuner X under Linux." "Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device" "But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor)." "Ok. Well, what is the licensing for that code? Is it GPL compatible?" "Not currently. So can we just make our driver closed source?" "Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch." "Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply". "Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core." "Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL." === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of "good will". They do it because they are compelled to by licenses or because there is no economically viable alternative. Mauro
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 09:30, Andreas Oberritter escreveu: > On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote: >> Em 21-06-2011 14:38, HoP escreveu: >>> 2011/6/21 Mauro Carvalho Chehab : Em 21-06-2011 12:09, Andreas Oberritter escreveu: > On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >> Em 21-06-2011 11:15, Andreas Oberritter escreveu: >>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter wrote: > Mauro and Devin, I think you're missing the point. This is not about > creating drivers in userspace. This is not about open or closed > source. > The "vtuner" interface, as implemented for the Dreambox, is used to > access remote tuners: Put x tuners into y boxes and access them from > another box as if they were local. It's used in conjunction with > further > software to receive the transport stream over a network connection. > Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. > You don't need it in order to create closed source drivers. You can > already create closed kernel drivers now. Also, you can create tuner > drivers in userspace using the i2c-dev interface. If you like to > connect > a userspace driver to a DVB API device node, you can distribute a > small > (open or closed) wrapper with it. So what are you arguing about? > Everything you're feared of can already be done since virtually > forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === "Devin, we need to support tuner X under Linux." "Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device" "But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor)." "Ok. Well, what is the licensing for that code? Is it GPL compatible?" "Not currently. So can we just make our driver closed source?" "Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch." "Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply". "Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core." "Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL." === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of "good will". They do it because they are compelled to by licenses or because there is no economically viable al
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/22 Mauro Carvalho Chehab : > Em 21-06-2011 14:38, HoP escreveu: >> 2011/6/21 Mauro Carvalho Chehab : >>> Em 21-06-2011 12:09, Andreas Oberritter escreveu: On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: > Em 21-06-2011 11:15, Andreas Oberritter escreveu: >> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: >>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter >>> wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The "vtuner" interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. >>> >>> I'm not missing the point at all. I realize exactly what Honza is >>> trying to accomplish (and from a purely technical standpoint, it's not >>> a bad approach) - but I'm talking about the effects of such a driver >>> being introduced which changes the kernel/userland licensing boundary >>> and has very real implications with how the in-kernel code is >>> accessed. >>> You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. >>> >>> I disagree. There is currently no API which allows applications to >>> issue tuning requests into the DVB core, and have those requests >>> proxied back out to userland where an application can then use i2c-dev >>> to tune the actual device. Meaning if somebody wants to write a >>> closed source userland application which controls the tuner, he/she >>> can do that (while not conforming to the DVB API). But if if he wants >>> to reuse the GPL licensed DVB core, he has to replace the entire DVB >>> core. >>> >>> The introduction of this patch makes it trivial for a third party to >>> provide closed-source userland support for tuners while reusing all >>> the existing GPL driver code that makes up the framework. >>> >>> I used to work for a vendor that makes tuners, and they do a bunch of >>> Linux work. And that work has resulted in a bunch of open source >>> drivers. I can tell you though that *every* conversation I've had >>> regarding a new driver goes something like this: >>> >>> === >>> "Devin, we need to support tuner X under Linux." >>> >>> "Great! I'll be happy to write a new GPL driver for the >>> tuner/demodulator/whatever for that device" >>> >>> "But to save time/money, we just want to reuse the Windows driver code >>> (or reference code from the vendor)." >>> >>> "Ok. Well, what is the licensing for that code? Is it GPL compatible?" >>> >>> "Not currently. So can we just make our driver closed source?" >>> >>> "Well, you can't reuse any of the existing DVB core functionality or >>> any of the other GPL drivers (tuners, bridges, demods), so you would >>> have rewrite all that from scratch." >>> >>> "Oh, that would be a ton of work. Can we maybe write some userland >>> stuff that controls the demodulator which we can keep closed source? >>> Since it's not in the kernel, the GPL won't apply". >>> >>> "Well, you can't really do that because there is no way for the DVB >>> core to call back out to userland when the application makes the >>> tuning request to the DVB core." >>> >>> "Oh, ok then. I guess we'll have to talk to the vendor and get them >>> to give us the reference driver code under the GPL." >>> === >>> >>> I can tell you without a doubt that if this driver were present in the >>> kernel, that going forward that vendor would have *zero* interest in >>> doing any GPL driver work. Why would they? Why give away the code >>> which could potentially help their competitors if they can keep it >>> safe and protected while still being able to reuse everybody else's >>> contributions? >>> >>> Companies don't contribute GPL code out of "good will". They do it >>> because they are compelled to by licenses or because there is no >>> economically viable alternative. >>> >>> Mauro, ultimately it is your decision as the maintainer which drivers >>> get accepted in to the kernel. I can tell you though that this will >>> be a very b
Re: [RFC] vtunerc - virtual DVB device driver
On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote: > Em 21-06-2011 14:38, HoP escreveu: >> 2011/6/21 Mauro Carvalho Chehab : >>> Em 21-06-2011 12:09, Andreas Oberritter escreveu: On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: > Em 21-06-2011 11:15, Andreas Oberritter escreveu: >> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: >>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter >>> wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The "vtuner" interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. >>> >>> I'm not missing the point at all. I realize exactly what Honza is >>> trying to accomplish (and from a purely technical standpoint, it's not >>> a bad approach) - but I'm talking about the effects of such a driver >>> being introduced which changes the kernel/userland licensing boundary >>> and has very real implications with how the in-kernel code is >>> accessed. >>> You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. >>> >>> I disagree. There is currently no API which allows applications to >>> issue tuning requests into the DVB core, and have those requests >>> proxied back out to userland where an application can then use i2c-dev >>> to tune the actual device. Meaning if somebody wants to write a >>> closed source userland application which controls the tuner, he/she >>> can do that (while not conforming to the DVB API). But if if he wants >>> to reuse the GPL licensed DVB core, he has to replace the entire DVB >>> core. >>> >>> The introduction of this patch makes it trivial for a third party to >>> provide closed-source userland support for tuners while reusing all >>> the existing GPL driver code that makes up the framework. >>> >>> I used to work for a vendor that makes tuners, and they do a bunch of >>> Linux work. And that work has resulted in a bunch of open source >>> drivers. I can tell you though that *every* conversation I've had >>> regarding a new driver goes something like this: >>> >>> === >>> "Devin, we need to support tuner X under Linux." >>> >>> "Great! I'll be happy to write a new GPL driver for the >>> tuner/demodulator/whatever for that device" >>> >>> "But to save time/money, we just want to reuse the Windows driver code >>> (or reference code from the vendor)." >>> >>> "Ok. Well, what is the licensing for that code? Is it GPL compatible?" >>> >>> "Not currently. So can we just make our driver closed source?" >>> >>> "Well, you can't reuse any of the existing DVB core functionality or >>> any of the other GPL drivers (tuners, bridges, demods), so you would >>> have rewrite all that from scratch." >>> >>> "Oh, that would be a ton of work. Can we maybe write some userland >>> stuff that controls the demodulator which we can keep closed source? >>> Since it's not in the kernel, the GPL won't apply". >>> >>> "Well, you can't really do that because there is no way for the DVB >>> core to call back out to userland when the application makes the >>> tuning request to the DVB core." >>> >>> "Oh, ok then. I guess we'll have to talk to the vendor and get them >>> to give us the reference driver code under the GPL." >>> === >>> >>> I can tell you without a doubt that if this driver were present in the >>> kernel, that going forward that vendor would have *zero* interest in >>> doing any GPL driver work. Why would they? Why give away the code >>> which could potentially help their competitors if they can keep it >>> safe and protected while still being able to reuse everybody else's >>> contributions? >>> >>> Companies don't contribute GPL code out of "good will". They do it >>> because they are compelled to by licenses or because there is no >>> economically viable alternative. >>> >>> Mauro, ultimately it is your decision as the maintainer which drivers >>> get accepted in to the kernel. I can tell you though that this will
Re: [RFC] vtunerc - virtual DVB device driver
Em 21-06-2011 14:38, HoP escreveu: > 2011/6/21 Mauro Carvalho Chehab : >> Em 21-06-2011 12:09, Andreas Oberritter escreveu: >>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 11:15, Andreas Oberritter escreveu: > On 06/21/2011 03:44 PM, Devin Heitmueller wrote: >> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter >> wrote: >>> Mauro and Devin, I think you're missing the point. This is not about >>> creating drivers in userspace. This is not about open or closed source. >>> The "vtuner" interface, as implemented for the Dreambox, is used to >>> access remote tuners: Put x tuners into y boxes and access them from >>> another box as if they were local. It's used in conjunction with further >>> software to receive the transport stream over a network connection. >>> Honza's code does the same thing. >> >> I'm not missing the point at all. I realize exactly what Honza is >> trying to accomplish (and from a purely technical standpoint, it's not >> a bad approach) - but I'm talking about the effects of such a driver >> being introduced which changes the kernel/userland licensing boundary >> and has very real implications with how the in-kernel code is >> accessed. >> >>> You don't need it in order to create closed source drivers. You can >>> already create closed kernel drivers now. Also, you can create tuner >>> drivers in userspace using the i2c-dev interface. If you like to connect >>> a userspace driver to a DVB API device node, you can distribute a small >>> (open or closed) wrapper with it. So what are you arguing about? >>> Everything you're feared of can already be done since virtually forever. >> >> I disagree. There is currently no API which allows applications to >> issue tuning requests into the DVB core, and have those requests >> proxied back out to userland where an application can then use i2c-dev >> to tune the actual device. Meaning if somebody wants to write a >> closed source userland application which controls the tuner, he/she >> can do that (while not conforming to the DVB API). But if if he wants >> to reuse the GPL licensed DVB core, he has to replace the entire DVB >> core. >> >> The introduction of this patch makes it trivial for a third party to >> provide closed-source userland support for tuners while reusing all >> the existing GPL driver code that makes up the framework. >> >> I used to work for a vendor that makes tuners, and they do a bunch of >> Linux work. And that work has resulted in a bunch of open source >> drivers. I can tell you though that *every* conversation I've had >> regarding a new driver goes something like this: >> >> === >> "Devin, we need to support tuner X under Linux." >> >> "Great! I'll be happy to write a new GPL driver for the >> tuner/demodulator/whatever for that device" >> >> "But to save time/money, we just want to reuse the Windows driver code >> (or reference code from the vendor)." >> >> "Ok. Well, what is the licensing for that code? Is it GPL compatible?" >> >> "Not currently. So can we just make our driver closed source?" >> >> "Well, you can't reuse any of the existing DVB core functionality or >> any of the other GPL drivers (tuners, bridges, demods), so you would >> have rewrite all that from scratch." >> >> "Oh, that would be a ton of work. Can we maybe write some userland >> stuff that controls the demodulator which we can keep closed source? >> Since it's not in the kernel, the GPL won't apply". >> >> "Well, you can't really do that because there is no way for the DVB >> core to call back out to userland when the application makes the >> tuning request to the DVB core." >> >> "Oh, ok then. I guess we'll have to talk to the vendor and get them >> to give us the reference driver code under the GPL." >> === >> >> I can tell you without a doubt that if this driver were present in the >> kernel, that going forward that vendor would have *zero* interest in >> doing any GPL driver work. Why would they? Why give away the code >> which could potentially help their competitors if they can keep it >> safe and protected while still being able to reuse everybody else's >> contributions? >> >> Companies don't contribute GPL code out of "good will". They do it >> because they are compelled to by licenses or because there is no >> economically viable alternative. >> >> Mauro, ultimately it is your decision as the maintainer which drivers >> get accepted in to the kernel. I can tell you though that this will >> be a very bad thing for the driver ecosystem as a whole - it will >> essentially make it trivial for vendors (some of which who are doing >> GPL work now) to p
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/22 Markus Rechberger : >> >> My very little opinion is that waving GPL is way to the hell. Nobody told me >> why similar technologies, in different kernel parts are acceptable, >> but not here. >> > > since a customer was trying to use this module the only feedback I can give > right now is that there are still some fundamental bugs in that work. > Just running it with some intuitive parameters (without having a dvb > device connected) caused > it to hang. > > ./vtunerc.i686 -c 1 > vtunerc: [5210 ../../vtunerc.c:349] debug: added frontend mode DVB-C > as mode 0, searching for tuner types 2 > vtunerc: [5210 ../../vtunerc.c:346] error: unknown tuner mode > specified: 1 allow values are: -s -S -s2 -S2 -c -t > it just never returned. > Never returned? How it is possible if just next line is exit(1) call? > DMESG: > vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer > vtunerc: [5207 ../../vtunerc.c:606] info: msg: 4096 completed > vtunerc: [5207 ../../vtunerc.c:506] info: vtuner message! > vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer > > ps fax | grep vtunerc: > 5194 pts/4 S 0:00 | \_ bash > 5210 pts/4 S+ 0:00 | \_ [vtunerc.i686] > > that way it's not good enough for inclusion yet anyway. I never wanted to get it include immediatelly. I never stated that. That is why subject of this mail starts with [RFC]. I wanted to know if such driver is even interesting by others and if so to get help from community having the code better. I was already noted that it is my first kernel driver and I understand that reviewing code by kernel hackers can help making code better. On the other hand I never thought that the code can be totally refused because of its nature. Even I all time was writing that all subsystem (kernel + userland daemons) are GPL. Marcus, tell the customer I'm just starting some howto document to guide all willing to test how it works through compilation and installation process. In parallel I'm going to address all hints gave me by Andreas, the only guy who even had a look at source. Anyway, I'm happy for any feedback, so thanks. /Honza -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
> > My very little opinion is that waving GPL is way to the hell. Nobody told me > why similar technologies, in different kernel parts are acceptable, > but not here. > since a customer was trying to use this module the only feedback I can give right now is that there are still some fundamental bugs in that work. Just running it with some intuitive parameters (without having a dvb device connected) caused it to hang. ./vtunerc.i686 -c 1 vtunerc: [5210 ../../vtunerc.c:349] debug: added frontend mode DVB-C as mode 0, searching for tuner types 2 vtunerc: [5210 ../../vtunerc.c:346] error: unknown tuner mode specified: 1 allow values are: -s -S -s2 -S2 -c -t it just never returned. DMESG: vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer vtunerc: [5207 ../../vtunerc.c:606] info: msg: 4096 completed vtunerc: [5207 ../../vtunerc.c:506] info: vtuner message! vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer ps fax | grep vtunerc: 5194 pts/4S 0:00 | \_ bash 5210 pts/4S+ 0:00 | \_ [vtunerc.i686] that way it's not good enough for inclusion yet anyway. Markus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab : > Em 21-06-2011 12:09, Andreas Oberritter escreveu: >> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >>> Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: > On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter > wrote: >> Mauro and Devin, I think you're missing the point. This is not about >> creating drivers in userspace. This is not about open or closed source. >> The "vtuner" interface, as implemented for the Dreambox, is used to >> access remote tuners: Put x tuners into y boxes and access them from >> another box as if they were local. It's used in conjunction with further >> software to receive the transport stream over a network connection. >> Honza's code does the same thing. > > I'm not missing the point at all. I realize exactly what Honza is > trying to accomplish (and from a purely technical standpoint, it's not > a bad approach) - but I'm talking about the effects of such a driver > being introduced which changes the kernel/userland licensing boundary > and has very real implications with how the in-kernel code is > accessed. > >> You don't need it in order to create closed source drivers. You can >> already create closed kernel drivers now. Also, you can create tuner >> drivers in userspace using the i2c-dev interface. If you like to connect >> a userspace driver to a DVB API device node, you can distribute a small >> (open or closed) wrapper with it. So what are you arguing about? >> Everything you're feared of can already be done since virtually forever. > > I disagree. There is currently no API which allows applications to > issue tuning requests into the DVB core, and have those requests > proxied back out to userland where an application can then use i2c-dev > to tune the actual device. Meaning if somebody wants to write a > closed source userland application which controls the tuner, he/she > can do that (while not conforming to the DVB API). But if if he wants > to reuse the GPL licensed DVB core, he has to replace the entire DVB > core. > > The introduction of this patch makes it trivial for a third party to > provide closed-source userland support for tuners while reusing all > the existing GPL driver code that makes up the framework. > > I used to work for a vendor that makes tuners, and they do a bunch of > Linux work. And that work has resulted in a bunch of open source > drivers. I can tell you though that *every* conversation I've had > regarding a new driver goes something like this: > > === > "Devin, we need to support tuner X under Linux." > > "Great! I'll be happy to write a new GPL driver for the > tuner/demodulator/whatever for that device" > > "But to save time/money, we just want to reuse the Windows driver code > (or reference code from the vendor)." > > "Ok. Well, what is the licensing for that code? Is it GPL compatible?" > > "Not currently. So can we just make our driver closed source?" > > "Well, you can't reuse any of the existing DVB core functionality or > any of the other GPL drivers (tuners, bridges, demods), so you would > have rewrite all that from scratch." > > "Oh, that would be a ton of work. Can we maybe write some userland > stuff that controls the demodulator which we can keep closed source? > Since it's not in the kernel, the GPL won't apply". > > "Well, you can't really do that because there is no way for the DVB > core to call back out to userland when the application makes the > tuning request to the DVB core." > > "Oh, ok then. I guess we'll have to talk to the vendor and get them > to give us the reference driver code under the GPL." > === > > I can tell you without a doubt that if this driver were present in the > kernel, that going forward that vendor would have *zero* interest in > doing any GPL driver work. Why would they? Why give away the code > which could potentially help their competitors if they can keep it > safe and protected while still being able to reuse everybody else's > contributions? > > Companies don't contribute GPL code out of "good will". They do it > because they are compelled to by licenses or because there is no > economically viable alternative. > > Mauro, ultimately it is your decision as the maintainer which drivers > get accepted in to the kernel. I can tell you though that this will > be a very bad thing for the driver ecosystem as a whole - it will > essentially make it trivial for vendors (some of which who are doing > GPL work now) to provide solutions that reuse the GPL'd DVB core > without having to make any of their stuff open source. > > Anyway,
Re: [RFC] vtunerc - virtual DVB device driver
2011/6/21 Mauro Carvalho Chehab : > Em 21-06-2011 10:44, Devin Heitmueller escreveu: > >> Mauro, ultimately it is your decision as the maintainer which drivers >> get accepted in to the kernel. I can tell you though that this will >> be a very bad thing for the driver ecosystem as a whole - it will >> essentially make it trivial for vendors (some of which who are doing >> GPL work now) to provide solutions that reuse the GPL'd DVB core >> without having to make any of their stuff open source. > > I was a little faster to answer to my previous emails. I'm not feeling > well today due to a strong pain on my backbone. > > So, let me explain what would be ok, from my POV: > > A kernelspace driver that will follow DVBv5 API and talk with wit another > device via the Kernel network stack, in order to access a remote Kernel board, > or a kernel board at the physical machine, for virtual machines. That means > that > the dvb stack won't be proxied to an userspace application. > > Something like: > > Userspace app (like kaffeine, dvr, etc) -> DVB net_tunnel driver -> Kernel > Network stack > > Kernel Network stack -> DVB net_tunnel driver -> DVB hardware > for such a design a developer should be fired ^^ Everything back to ring 0, however I guess that particular developer who "designed" this does not know about that security concept, otherwise he wouldn't propose to put such things into kernelspace. and from the kernel network stack you go via TCP and connect to whoever you want (particular userspace daemon with all the implementation). Aside of the security issue which it introduces you won't even protect what you try to protect because you cannot control the connection. It would be interesting if someone would implement it that way now, so Mauro disqualified himself with this proposal. Although please continue I'll keep watching, either result (supporting or not supporting it) is fine with me. Markus > In other words, the "DVB net_tunnel" driver will take care of using the > network stack, implement Kernel namespaces, etc, in order to allow > virtualizing > a remote hardware, without needing any userspace driver for doing that > (well, except, of course, for the standard network userspace applications for > DNS solving, configuring IP routes, etc). > > Cheers, > Mauro > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
