[pvrusb2] Re: pvrusb2 driver going into v4l...

Mike Isely isely at isely.net
Wed Nov 9 01:41:07 CST 2005


On Tue, 8 Nov 2005, Frans Meulenbroeks wrote:

> Mike,
>
> This seems a good way forward, but it is unclear to me
> what we loose/where the incompatibilities are.

The issue I was discussing here only dealt with maintaining backwards 
compatibility with older kernels and/or versions of ivtv.  For the driver 
going into V4L this is less of an issue, but if I try to continue 
maintaining that sort of compatibility with more bleeding edge out-of-tree 
snapshots, then the code will diverge, something which would complicate 
putting this into V4L in the first place.

>
> I would definitely regret it if this means loosing the
> sys interface (probably with the serial nr) as
> discussed before.

This is a whole different issue.  At this point I have no intent of seeing 
the sysfs interface go away.  I mentioned a while back that this might be 
a problem, but right now I am not treating it as such and plan on it being 
there along with everything else.

There is a also a debugging interface hiding in sysfs as well.  It's only 
really documented to the extent that you have to use a piece of that in 
order to do the full manual firmware extraction (which almost nobody ever 
needs to do).  This debug interface includes a simple command interpreter, 
and I know this is a type of thing which should not really be going into 
the kernel.  I've already raised this issue with Mauro; he replied that it 
may be able to go in anyway.  However I'm working on an idea that will 
allow me to keep the debug interface out-of-tree if needed yet possibly 
still be loadable as a separate module into the kernel-resident pvrusb2 
driver.  So I'm not that concerned about this issue.

Actually, I'm thinking about making the debug interface a full fledged 
sibling interface right alongside sysfs itself and V4L, and using that 
obvious boundary as a module loading shearing layer - then we could have 
pvrusb2.ko as the core driver, pvrusb2-sysfs.ko as the sysfs binding, 
pvrusb2-v4l.ko as a the V4L binding, pvrusb2-debug.ko as the debug 
interface binding, and maybe in the future pvrusb2-dvb.ko as the 
hypothetical dvb binding.  But that's just a crazy idea bouncing around in 
my head right now and I still have to think about it some more...


>
> If the names in sys change, I don't mind that much.
> For the programming interface: Well, I use the sys
> interface only (being a lazy sod), so I really have no
> opinion here. I'd like to know though, because if that
> changes I definitely do not want to move from the sys
> interface to a programming interface with my proggie
> at this point in time.

I don't have any plans at this point of changing any names in sysfs 
related to this driver, beyond *possibly* an impact with the 2 names 
related to the debug interface (neither of which I think anyone is using 
anyway).  So you shouldn't have to worry about anything here.

   -Mike

-- 
                         |         Mike Isely          |     PGP fingerprint
      Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                         |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                         |                             |


More information about the pvrusb2 mailing list