[lkml]   [2011]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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:
>> No matter if they are read or write, all of them call this function:
>> 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.



 \ /
  Last update: 2011-12-06 18:37    [W:0.102 / U:0.896 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site