From: Hans Verkuil <firstname.lastname@example.org> To: Mauro Carvalho Chehab <email@example.com>, "Daniel W. S. Almeida" <firstname.lastname@example.org> Cc: "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org> Subject: Re: [Linux-kernel-mentees] [v10 0/4] media: vidtv: Implement a virtual DVB driver Date: Mon, 14 Sep 2020 10:33:34 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 12/09/2020 19:57, Mauro Carvalho Chehab wrote: > Em Sat, 12 Sep 2020 11:49:01 -0300 > "Daniel W. S. Almeida" <email@example.com> escreveu: > >> Hi Hans and Mauro & all >> >> >>> Why the dvb_ prefix? All virtual drivers just start with 'vi'. >>> >>> And wouldn't it make more sense to call dvb_vidtv_bridge.ko just vidtv.ko? >>> Just like the other virtual media drivers? >> >> I guess Mauro was the one to come up with the dvb_* prefix for the >> kernel modules for the reasons he explicited up in this thread. >> >> As far as dvb_vidtv_bridge.ko and vidtv_bridge.c, I just wanted to be >> verbose so that people would look at this and see that it is the code >> for a bridge driver, since this is also supposed to be a template. >> >> Also because I had some trouble myself figuring out what was what when >> first browsing through other dvb drivers. That said, I am 100% onboard >> with renaming this to vidtv.ko or whatever seems more appropiate :) > > Let us think a little bit about that. > >> >> >>> Yet, I agree with you that at least an alias is needed. >>> earlier today, I wrote a patch with such purpose: >> >> If you all would like to just leave this at that ^ I am also ok with it. >> >>> For regression testing of vidtv during the daily build it would be >> great if >>> the contrib/test/test-media script can be enhanced to include vidtv. >> >> Sure, I can do that if you'd like. Can you provide some tips on how to >> get started? :) > > Hans can explain it better, but the hole idea is to have a set of > userspace apps that will ensure that drivers will properly implement > the DVB API. > > I suspect that, before that (or together with such tooling), we need > to properly implement the frontend ioctl, validating the per delivery > system parameters, as, right now, it just accepts anything from > userspace. Daniel, if you look at the test-media script, then you'll see that it has separate sections for each virtual driver. It's probably best to look at the vim2m driver tests since that's the easiest. It loads the module, then it starts v4l2-compliance to test the API. This utility basically tries all V4L2 APIs and checks that the driver conforms to the spec. Note that you see options like '-m platform:vim2m' that selects which /dev/media device to use based on the name and v4l2-compliance (or v4l2-ctl with the -z option) then walks the topology of the media device and tests all interfaces it finds. Hence my question about media controller support in vidtv: this should be supported there as well since it allows you to write these test sequences without having to know which /dev/fooX device should be used. After the compliance test is run the script tests unbind/bind (always a nasty test) and checks for memory leaks (if enabled in the kernel). Much of this test sequence can be copied for vidtv, but you need something else for the compliance test. It would for now be enough to have some quick check with the existing dvb utils from v4l-utils to see that the basics work. IMHO I think a dtv-compliance utility along the lines of v4l2-compliance and cec-compliance should be created. I'm actually wondering whether the dtv compliance tests shouldn't be part of v4l2-compliance (which would have to be renamed to media-compliance in that case) since there are hybrid drivers supporting both in the same media topology. This would make compliance tests possible where analog/digital TV mode handling is tested (i.e. if analog TV is in use, then trying to use digital TV would return EBUSY and vice versa). It would require some work in v4l2-compliance.cpp to make this possible, but I can do that myself. Compliance tests have proven to be a great method of testing for regressions and testing drivers in general. Note that it takes a lot of time to create good compliance tests, but you just start with some simple tests and expand it over time. Regards, Hans _______________________________________________ Linux-kernel-mentees mailing list Linuxfirstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
next prev parent reply other threads:[~2020-09-14 8:33 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-21 12:58 Daniel W. S. Almeida 2020-08-21 12:58 ` [Linux-kernel-mentees] [v10 1/4] media: vidtv: implement a tuner driver Daniel W. S. Almeida 2020-08-21 12:58 ` [Linux-kernel-mentees] [v10 2/4] media: vidtv: implement a demodulator driver Daniel W. S. Almeida 2020-08-21 12:58 ` [Linux-kernel-mentees] [v10 3/4] media: vidtv: add a bridge driver Daniel W. S. Almeida 2020-09-15 11:53 ` Geert Uytterhoeven 2020-09-15 13:26 ` Daniel W. S. Almeida 2020-09-15 13:35 ` Geert Uytterhoeven 2020-09-15 18:13 ` Daniel W. S. Almeida 2020-09-16 7:01 ` Mauro Carvalho Chehab 2020-08-21 12:58 ` [Linux-kernel-mentees] [v10 4/4] media: Documentation: vidtv: Add ReST documentation for vidtv Daniel W. S. Almeida 2020-09-11 8:02 ` [Linux-kernel-mentees] [v10 0/4] media: vidtv: Implement a virtual DVB driver Mauro Carvalho Chehab 2020-09-11 12:18 ` Daniel W. S. Almeida 2020-09-11 13:10 ` Mauro Carvalho Chehab 2020-09-11 13:56 ` Mauro Carvalho Chehab 2020-09-12 2:54 ` Daniel W. S. Almeida 2020-09-12 7:38 ` Mauro Carvalho Chehab 2020-09-12 8:21 ` Hans Verkuil 2020-09-12 9:15 ` Mauro Carvalho Chehab 2020-09-12 14:49 ` Daniel W. S. Almeida 2020-09-12 17:57 ` Mauro Carvalho Chehab 2020-09-14 8:33 ` Hans Verkuil [this message] 2020-09-12 8:35 ` Hans Verkuil
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [Linux-kernel-mentees] [v10 0/4] media: vidtv: Implement a virtual DVB driver' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).