[PATCH 0/4] media Kconfig reorg - part 2

[Mauro Carvalho Chehab]

Em Thu, 26 Mar 2020 12:13:33 +0200
Laurent Pinchart <laurent.pinchart at ideasonboard.com> escreveu:

> > > I'm not sure to follow you. Are you implying that this patch series,
> > > which Helen has tested against a real user, not an experienced kernel
> > > hacker, may make the configuration options more difficult for kernel
> > > hackers, but improves the situation for users ?  
> > 
> > Come on, it is not harder for Kernel hackers. It is just different than
> > what it used to be before the changes.  
> 
> Sorry, I didn't meant to say it would be more complex for me (I mostly
> don't use menuconfig anyway, I edit the .config file manually :-)), but
> I was reading your e-mail as implying that, and was wondering if it was
> me misreading it.

So, the new design will be less complex for you, as some dependencies were
changed to be automatically set when a driver is selected (media controller
and V4L2 subdev APIs) ;-)

> 
> > At the above experience, at the
> > very first time this Kernel hacker looked on it, it was able to figure
> > out how to enable the driver. I bet that, if you now repeat the experiment
> > with the same guy, he would be able to enable another driver a lot quicker.
> > 
> > My view is that, with the option of either enable or disable the
> > filtering mechanism, it will be easier for everybody:
> > 
> > - Distro maintainers for PCs can just disable platform and
> >   test drivers, and keep the other drivers enabled;
> > 
> > - An experienced Kernel hacker will disable the filter and select
> >   the needed drivers directly.
> > 
> > - An user wanting to test a driver with new patches (or a new driver)
> >   use the filters to select the USB driver he needs (probably using the
> >   media_tree.git, in order to see only the media options).  
> 
> My personal view is that this makes things more complex, and more
> complexity usually means less clarity. If we want to be serious about
> the usability of our Kconfig menu, we should get real users involved in
> the design, at least by testing it on them, and getting feedback.
> Otherwise we'll just be a bunch of kernel developers sitting in our
> ivory tower thinking we know better than our users what is good for
> them.

The entire thing started by a proposal to change, in a way that it
would be make things easier for m2m developers but harder for
normal users.

My proposal is to keep both behaviors, with a menu that would
allow switching between those two different behaviors. 

So, it should make both groups happy :-)

Not much complexity added. It is the other way around: I took the
time to do several Kconfig cleanups, in order to make the Kconfig 
files cleaner and better organized (both internally and visually).

-

I don't object getting feedback from real users, but if we're
willing to use such feedback in a consistent way, we need to have
a group of people that could statistically represent the diversity
that we have with the people which builds their own kernels.

> > See, for some random distro maintainer, new Kconfig symbols pops up
> > every time. Enabling all of them is usually a very bad idea. So, a
> > filtering mechanism that would, for example, hide test and skeleton
> > drivers to be built is a very nice feat, as it means a lot less
> > symbols for them to study and decide whether such new options should
> > be enabled or not  
> 
> The fact that test drivers are not shipped by some distros is annoying
> for developers ;-) But that's a very small minority, and out of topic.

Yes, agreed. Things could be easier for us if we could ask people
to use a test driver when reporting certain bugs.

On the other hand, having a test driver shipped by default together
with a production Kernel don't make any sense for most usages. It
would just make the Kernel package bigger and would never be used
by the vast majority of users. It would also mean more work for
security people that would be trying to do OS hardening.

Well, Fedora has a kernel-debug Kernel, meant to be used
when someone finds an issue on production and may require extra stuff
to debug the Kernel. IMHO, it makes a lot of sense to have those test 
drivers shipped there (perhaps packaged in separate, like on a 
kernel-debug-media-test rpm).



Thanks,
Mauro