| Message ID | cover.1585151701.git.mchehab+huawei@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | media Kconfig reorg - part 2 | expand |
Hello, On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote: > That's the second part of media Kconfig changes. The entire series is > at: > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general. I asked him to enable Vimc (from default configs, where multimedia starts disabled). He knows that Vimc is a virtual camera driver, and this is how he behaved: === Start of experiment: * He pressed '/' and searched for vimc to see the location path. * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI). * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers". * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu). * He seemed a bit lost, going back and forth in the menus a couple of times. * Then he pressed '/' again to search for vimc and see the location path, and he realized that there should be an option called "V4L test drivers" under "Media drivers" that is not showing up. * He went back to "Media device types" again and start re-reading the options. * He selected "Cameras and video grabbers" ant went back to "Media drivers". * He sees "V4L test drivers", selects it, and enter this menu. * He selects "Virtual Media Controller Driver". I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need to combine "Test drivers" with "Cameras and video grabbers". He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough. Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't realized by himself until that moment, nor tried it out to see what would happen). He mentioned that hiding is nice, because it shows less options, but not very nice to search for something. He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner. === End of experiment This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to kernel development (kernel dev newbies for instance). Just another remark from me: From the default config, "Media drivers" shows USB and PCI, and selecting those doesn't do anything, and people can even think that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers shows up. I hope this helps Helen > > It addresses some issues I noticed when reviewing the series, and do > some changes on how things will be displayed. > > It also simplify dependencencies on media-controller-dependent drivers, > by auto-selecting the needed deps. > > It should be noticed that the media controller may also optionally > selected for several other drivers, so there is still a prompt to allow > manually enabling it, in the case it was not auto-selected. > > PS.: While not needed anymore, because all dependent drivers auto > select, at least for now, I opted to keep the prompt for: > > - VIDEO_V4L2_SUBDEV_API > > The rationale is that there are a few drivers that can optionally depend > on it (like tvp5150). So, better to keep the dependency, in order to be > able to test those drivers with and without the option. > > - MEDIA_CONTROLLER_REQUEST_API > > The rationale is that there are some warnings at the Request API, and > it would be good to keep it, at least while drivers are on staging. > > Mauro Carvalho Chehab (4): > media: dvb-core: Kconfig: default to use dynamic minors > media: Kconfig files: use select for V4L2 subdevs and MC > media: i2c/Kconfig: reorganize items there > media: Kconfig: don't use visible for device type select > > drivers/media/Kconfig | 25 +- > drivers/media/dvb-core/Kconfig | 1 + > drivers/media/i2c/Kconfig | 406 +++++++++++------- > drivers/media/i2c/et8ek8/Kconfig | 4 +- > drivers/media/i2c/m5mols/Kconfig | 5 +- > drivers/media/i2c/smiapp/Kconfig | 5 +- > drivers/media/pci/cobalt/Kconfig | 4 +- > drivers/media/pci/intel/ipu3/Kconfig | 4 +- > drivers/media/pci/sta2x11/Kconfig | 6 +- > drivers/media/platform/Kconfig | 28 +- > drivers/media/platform/am437x/Kconfig | 4 +- > drivers/media/platform/atmel/Kconfig | 4 +- > drivers/media/platform/cadence/Kconfig | 8 +- > drivers/media/platform/exynos4-is/Kconfig | 5 +- > drivers/media/platform/rcar-vin/Kconfig | 8 +- > .../media/platform/sunxi/sun4i-csi/Kconfig | 4 +- > .../media/platform/sunxi/sun6i-csi/Kconfig | 4 +- > drivers/media/platform/xilinx/Kconfig | 4 +- > drivers/media/spi/Kconfig | 4 +- > drivers/media/test_drivers/vimc/Kconfig | 4 +- > drivers/staging/media/hantro/Kconfig | 5 +- > drivers/staging/media/imx/Kconfig | 5 +- > drivers/staging/media/ipu3/Kconfig | 3 +- > drivers/staging/media/omap4iss/Kconfig | 4 +- > drivers/staging/media/rkisp1/Kconfig | 4 +- > drivers/staging/media/sunxi/cedrus/Kconfig | 5 +- > 26 files changed, 349 insertions(+), 214 deletions(-) >
Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike <helen.koike@collabora.com> escreveu: > Hello, > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote: > > That's the second part of media Kconfig changes. The entire series is > > at: > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig > > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general. > I asked him to enable Vimc (from default configs, where multimedia starts disabled). > He knows that Vimc is a virtual camera driver, and this is how he behaved: > > === Start of experiment: > > * He pressed '/' and searched for vimc to see the location path. > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI). > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers". > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu). > * He seemed a bit lost, going back and forth in the menus a couple of times. > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there > should be an option called "V4L test drivers" under "Media drivers" that is not showing up. > * He went back to "Media device types" again and start re-reading the options. > * He selected "Cameras and video grabbers" ant went back to "Media drivers". > * He sees "V4L test drivers", selects it, and enter this menu. > * He selects "Virtual Media Controller Driver". > > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need > to combine "Test drivers" with "Cameras and video grabbers". > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough. > > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't > realized by himself until that moment, nor tried it out to see what would happen). > > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something. > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner. That's easy to solve: all it needs is to add something similar to this at drivers/media/Kconfig: + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER" + visible if MEDIA_SUPPORT_FILTER + + comment "All available drivers are shown below" + visible if !MEDIA_SUPPORT_FILTER + menu "Media drivers" source "drivers/media/usb/Kconfig" > === End of experiment > > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to > kernel development (kernel dev newbies for instance). > > Just another remark from me: > > From the default config, "Media drivers" shows USB and PCI, Well, assuming that there are 2 billion computers, 1% with Linux installed, and 10% of them have a media device (camera or TV), we have about 2 millions of people running Linux. That excludes Android and Embedded devices, where people usually don't touch. During an entire year, there are about 4000 of Kernel developers that has at least one patch accepted upstream (this number includes developers for Android and other SoCs). Also, the number of Kernel developers submitting patches upstream for the media subsystem is around 20-40 people along an year. So, about 99,9998% of the users using the media subsystems aren't Kernel hackers. I bet that almost all of those will either need to enable USB or a PCI driver. Granted, 99,9998% seems too optimistic, but, assuming that this would reduce to something like 80% (e. g. only 200 users would ever try to build a media driver, with is a *very conservative* number) this is still a lot more than the number of media Kernel developers. Also, a Kernel hacker will sooner or later find a way to enable it. A normal user may find it a lot more trickier and will very likely require more support, if the menus are too technical and the default options are wrong. - Even with that, based on your small experiment (of someone from the area), I suspect that, if you had asked him to enable, for example, em28xx or dvbsky (with are some of the most popular drivers those days), he would be able to enable it a lot faster. > and selecting those doesn't do anything, and people can even think > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers > shows up. It is hard to comment on individual experiments. In the past, our Kconfig system were like that: written for technical people with background on computer engineering and some experience building the Kernel. E.g. people that knows that "/" activates a search mechanism at the Kernel building system. We usually had to spend *a lot of time* both on IRC and on e-mail explaining people that just want to have their card supported, how to do that. After the reorg (with added those more user-faced interfaces), the number of people with problems reduced a lot. Btw, if one tries to compile from media-build (with lots of users do), this is even more relevant. Thanks, Mauro
Hi Mauro, On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote: > Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu: > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote: > > > That's the second part of media Kconfig changes. The entire series is > > > at: > > > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig > > > > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general. > > I asked him to enable Vimc (from default configs, where multimedia starts disabled). > > He knows that Vimc is a virtual camera driver, and this is how he behaved: > > > > === Start of experiment: > > > > * He pressed '/' and searched for vimc to see the location path. > > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI). > > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers". > > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu). > > * He seemed a bit lost, going back and forth in the menus a couple of times. > > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there > > should be an option called "V4L test drivers" under "Media drivers" that is not showing up. > > * He went back to "Media device types" again and start re-reading the options. > > * He selected "Cameras and video grabbers" ant went back to "Media drivers". > > * He sees "V4L test drivers", selects it, and enter this menu. > > * He selects "Virtual Media Controller Driver". > > > > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need > > to combine "Test drivers" with "Cameras and video grabbers". > > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough. > > > > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't > > realized by himself until that moment, nor tried it out to see what would happen). > > > > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something. > > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner. > > That's easy to solve: all it needs is to add something similar > to this at drivers/media/Kconfig: > > + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER" > + visible if MEDIA_SUPPORT_FILTER > + > + comment "All available drivers are shown below" > + visible if !MEDIA_SUPPORT_FILTER > + > menu "Media drivers" > > source "drivers/media/usb/Kconfig" > > > === End of experiment > > > > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check > > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to > > kernel development (kernel dev newbies for instance). > > > > Just another remark from me: > > > > From the default config, "Media drivers" shows USB and PCI, > > Well, assuming that there are 2 billion computers, 1% with Linux > installed, and 10% of them have a media device (camera or TV), > we have about 2 millions of people running Linux. That excludes > Android and Embedded devices, where people usually don't touch. > > During an entire year, there are about 4000 of Kernel developers > that has at least one patch accepted upstream (this number > includes developers for Android and other SoCs). Also, the > number of Kernel developers submitting patches upstream for the > media subsystem is around 20-40 people along an year. $ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l 215 There's some duplication of e-mail addresses, but it's still roughly an order or magnitude bigger (and it's not counting staging, headers or documentation). > So, about 99,9998% of the users using the media subsystems aren't > Kernel hackers. I bet that almost all of those will either need > to enable USB or a PCI driver. And the extremely vast majority of these will never enable a kernel option because they will never compile a kernel. They don't even know what a kernel is :-) > Granted, 99,9998% seems too optimistic, but, assuming that this > would reduce to something like 80% (e. g. only 200 users > would ever try to build a media driver, with is a *very conservative* > number) this is still a lot more than the number of media Kernel > developers. > > Also, a Kernel hacker will sooner or later find a way to enable it. > A normal user may find it a lot more trickier and will very likely > require more support, if the menus are too technical and the > default options are wrong. 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 ? > > - > > Even with that, based on your small experiment (of someone from the > area), I suspect that, if you had asked him to enable, for example, > em28xx or dvbsky (with are some of the most popular drivers > those days), he would be able to enable it a lot faster. This is the *only* real piece of evidence we have, let's not assume we know better. > > and selecting those doesn't do anything, and people can even think > > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers > > shows up. > > It is hard to comment on individual experiments. In the past, our > Kconfig system were like that: written for technical people with > background on computer engineering and some experience building the > Kernel. > > E.g. people that knows that "/" activates a search mechanism at > the Kernel building system. > > We usually had to spend *a lot of time* both on IRC and on e-mail > explaining people that just want to have their card supported, > how to do that. After the reorg (with added those more user-faced > interfaces), the number of people with problems reduced a lot. Don't you think that could come mainly from better support for media devices in distributions ? > Btw, if one tries to compile from media-build (with lots of users > do), this is even more relevant. Can you quantify "lots of users" ?
Em Thu, 26 Mar 2020 00:13:43 +0200 Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu: > Hi Mauro, > > On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote: > > Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu: > > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote: > > > > That's the second part of media Kconfig changes. The entire series is > > > > at: > > > > > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig > > > > > > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general. > > > I asked him to enable Vimc (from default configs, where multimedia starts disabled). > > > He knows that Vimc is a virtual camera driver, and this is how he behaved: > > > > > > === Start of experiment: > > > > > > * He pressed '/' and searched for vimc to see the location path. > > > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI). > > > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers". > > > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu). > > > * He seemed a bit lost, going back and forth in the menus a couple of times. > > > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there > > > should be an option called "V4L test drivers" under "Media drivers" that is not showing up. > > > * He went back to "Media device types" again and start re-reading the options. > > > * He selected "Cameras and video grabbers" ant went back to "Media drivers". > > > * He sees "V4L test drivers", selects it, and enter this menu. > > > * He selects "Virtual Media Controller Driver". > > > > > > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need > > > to combine "Test drivers" with "Cameras and video grabbers". > > > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough. > > > > > > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't > > > realized by himself until that moment, nor tried it out to see what would happen). > > > > > > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something. > > > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner. > > > > That's easy to solve: all it needs is to add something similar > > to this at drivers/media/Kconfig: > > > > + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER" > > + visible if MEDIA_SUPPORT_FILTER > > + > > + comment "All available drivers are shown below" > > + visible if !MEDIA_SUPPORT_FILTER > > + > > menu "Media drivers" > > > > source "drivers/media/usb/Kconfig" > > > > > === End of experiment > > > > > > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check > > > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to > > > kernel development (kernel dev newbies for instance). > > > > > > Just another remark from me: > > > > > > From the default config, "Media drivers" shows USB and PCI, > > > > Well, assuming that there are 2 billion computers, 1% with Linux > > installed, and 10% of them have a media device (camera or TV), > > we have about 2 millions of people running Linux. That excludes > > Android and Embedded devices, where people usually don't touch. > > > > During an entire year, there are about 4000 of Kernel developers > > that has at least one patch accepted upstream (this number > > includes developers for Android and other SoCs). Also, the > > number of Kernel developers submitting patches upstream for the > > media subsystem is around 20-40 people along an year. > > $ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l > 215 > > There's some duplication of e-mail addresses, but it's still roughly an > order or magnitude bigger (and it's not counting staging, headers or > documentation). > > > So, about 99,9998% of the users using the media subsystems aren't > > Kernel hackers. I bet that almost all of those will either need > > to enable USB or a PCI driver. > > And the extremely vast majority of these will never enable a kernel > option because they will never compile a kernel. They don't even know > what a kernel is :-) > > > Granted, 99,9998% seems too optimistic, but, assuming that this > > would reduce to something like 80% (e. g. only 200 users > > would ever try to build a media driver, with is a *very conservative* > > number) this is still a lot more than the number of media Kernel > > developers. > > > > Also, a Kernel hacker will sooner or later find a way to enable it. > > A normal user may find it a lot more trickier and will very likely > > require more support, if the menus are too technical and the > > default options are wrong. > > 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. 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). > > - > > > > Even with that, based on your small experiment (of someone from the > > area), I suspect that, if you had asked him to enable, for example, > > em28xx or dvbsky (with are some of the most popular drivers > > those days), he would be able to enable it a lot faster. > > This is the *only* real piece of evidence we have, let's not assume we > know better. > > > > and selecting those doesn't do anything, and people can even think > > > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers > > > shows up. > > > > It is hard to comment on individual experiments. In the past, our > > Kconfig system were like that: written for technical people with > > background on computer engineering and some experience building the > > Kernel. > > > > E.g. people that knows that "/" activates a search mechanism at > > the Kernel building system. > > > > We usually had to spend *a lot of time* both on IRC and on e-mail > > explaining people that just want to have their card supported, > > how to do that. After the reorg (with added those more user-faced > > interfaces), the number of people with problems reduced a lot. > > Don't you think that could come mainly from better support for media > devices in distributions ? > > > Btw, if one tries to compile from media-build (with lots of users > > do), this is even more relevant. > > Can you quantify "lots of users" ? Enough to make us to decide that re-working the Kconfig menus and add the MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT would worth the efforts. Guess what? The efforts were fully paid, as it reduced a lot the amount of time we had to weekly spend helping people to build their Kernels in order to test support for their new hardware. It also helped a lot to set the right Kconfig options on distros. I did my contributions on that time by improving Fedora and on RHEL, making their build rely on MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT. 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 Thanks, Mauro
Hi Mauro, On Thu, Mar 26, 2020 at 09:28:32AM +0100, Mauro Carvalho Chehab wrote: > Em Thu, 26 Mar 2020 00:13:43 +0200 Laurent Pinchart escreveu: > > On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote: > > > Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu: > > > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote: > > > > > That's the second part of media Kconfig changes. The entire series is > > > > > at: > > > > > > > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig > > > > > > > > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general. > > > > I asked him to enable Vimc (from default configs, where multimedia starts disabled). > > > > He knows that Vimc is a virtual camera driver, and this is how he behaved: > > > > > > > > === Start of experiment: > > > > > > > > * He pressed '/' and searched for vimc to see the location path. > > > > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI). > > > > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers". > > > > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu). > > > > * He seemed a bit lost, going back and forth in the menus a couple of times. > > > > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there > > > > should be an option called "V4L test drivers" under "Media drivers" that is not showing up. > > > > * He went back to "Media device types" again and start re-reading the options. > > > > * He selected "Cameras and video grabbers" ant went back to "Media drivers". > > > > * He sees "V4L test drivers", selects it, and enter this menu. > > > > * He selects "Virtual Media Controller Driver". > > > > > > > > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need > > > > to combine "Test drivers" with "Cameras and video grabbers". > > > > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough. > > > > > > > > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't > > > > realized by himself until that moment, nor tried it out to see what would happen). > > > > > > > > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something. > > > > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner. > > > > > > That's easy to solve: all it needs is to add something similar > > > to this at drivers/media/Kconfig: > > > > > > + comment "Drivers are filtered by MEDIA_SUPPORT_FILTER" > > > + visible if MEDIA_SUPPORT_FILTER > > > + > > > + comment "All available drivers are shown below" > > > + visible if !MEDIA_SUPPORT_FILTER > > > + > > > menu "Media drivers" > > > > > > source "drivers/media/usb/Kconfig" > > > > > > > === End of experiment > > > > > > > > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check > > > > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to > > > > kernel development (kernel dev newbies for instance). > > > > > > > > Just another remark from me: > > > > > > > > From the default config, "Media drivers" shows USB and PCI, > > > > > > Well, assuming that there are 2 billion computers, 1% with Linux > > > installed, and 10% of them have a media device (camera or TV), > > > we have about 2 millions of people running Linux. That excludes > > > Android and Embedded devices, where people usually don't touch. > > > > > > During an entire year, there are about 4000 of Kernel developers > > > that has at least one patch accepted upstream (this number > > > includes developers for Android and other SoCs). Also, the > > > number of Kernel developers submitting patches upstream for the > > > media subsystem is around 20-40 people along an year. > > > > $ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l > > 215 > > > > There's some duplication of e-mail addresses, but it's still roughly an > > order or magnitude bigger (and it's not counting staging, headers or > > documentation). > > > > > So, about 99,9998% of the users using the media subsystems aren't > > > Kernel hackers. I bet that almost all of those will either need > > > to enable USB or a PCI driver. > > > > And the extremely vast majority of these will never enable a kernel > > option because they will never compile a kernel. They don't even know > > what a kernel is :-) > > > > > Granted, 99,9998% seems too optimistic, but, assuming that this > > > would reduce to something like 80% (e. g. only 200 users > > > would ever try to build a media driver, with is a *very conservative* > > > number) this is still a lot more than the number of media Kernel > > > developers. > > > > > > Also, a Kernel hacker will sooner or later find a way to enable it. > > > A normal user may find it a lot more trickier and will very likely > > > require more support, if the menus are too technical and the > > > default options are wrong. > > > > 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. > 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. > > > - > > > > > > Even with that, based on your small experiment (of someone from the > > > area), I suspect that, if you had asked him to enable, for example, > > > em28xx or dvbsky (with are some of the most popular drivers > > > those days), he would be able to enable it a lot faster. > > > > This is the *only* real piece of evidence we have, let's not assume we > > know better. > > > > > > and selecting those doesn't do anything, and people can even think > > > > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers > > > > shows up. > > > > > > It is hard to comment on individual experiments. In the past, our > > > Kconfig system were like that: written for technical people with > > > background on computer engineering and some experience building the > > > Kernel. > > > > > > E.g. people that knows that "/" activates a search mechanism at > > > the Kernel building system. > > > > > > We usually had to spend *a lot of time* both on IRC and on e-mail > > > explaining people that just want to have their card supported, > > > how to do that. After the reorg (with added those more user-faced > > > interfaces), the number of people with problems reduced a lot. > > > > Don't you think that could come mainly from better support for media > > devices in distributions ? > > > > > Btw, if one tries to compile from media-build (with lots of users > > > do), this is even more relevant. > > > > Can you quantify "lots of users" ? > > Enough to make us to decide that re-working the Kconfig menus and > add the MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT would worth the > efforts. > > Guess what? The efforts were fully paid, as it reduced a lot the > amount of time we had to weekly spend helping people to build their > Kernels in order to test support for their new hardware. > > It also helped a lot to set the right Kconfig options on distros. > I did my contributions on that time by improving Fedora and on RHEL, > making their build rely on MEDIA_SUPPORT_* and MEDIA_SUBDRV_AUTOSELECT. > > 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.
Em Thu, 26 Mar 2020 12:13:33 +0200 Laurent Pinchart <laurent.pinchart@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
On Wed, Mar 25, 2020 at 04:36:31PM -0300, Helen Koike wrote: > Hello, > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote: > > That's the second part of media Kconfig changes. The entire series is > > at: > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig > > I made a quick experiment (using this branch) with someone who works > with the kernel for his master degree, but doesn't have much experience in kernel development in general. > I asked him to enable Vimc (from default configs, where multimedia starts disabled). The whole config system is really outdated. It should be that this task was done with a command like "kconfig enable vimc". It would ask necessary questions and pull in the dependencies automatically. Twenty years ago it made sense to go through the menus and select things one by one. Does anyone really start from defconfig any more? Surely everyone starts with a known working config and just enables specific options. I started to hack together some code to create a kconfig program to enable and disable options. The problem is that all library code assumes we want to display menus so it was a lot of work and I gave up. regards, dan carpenter
Em Wed, 1 Apr 2020 13:59:49 +0300 Dan Carpenter <dan.carpenter@oracle.com> escreveu: > On Wed, Mar 25, 2020 at 04:36:31PM -0300, Helen Koike wrote: > > Hello, > > > > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote: > > > That's the second part of media Kconfig changes. The entire series is > > > at: > > > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig > > > > I made a quick experiment (using this branch) with someone who works > > with the kernel for his master degree, but doesn't have much experience in kernel development in general. > > I asked him to enable Vimc (from default configs, where multimedia starts disabled). > > The whole config system is really outdated. Agreed. Btw, when compiled against Qt 5.14, "make xconfig" is currently broken. I'm sending in a few some fixup patches for it. > It should be that this task was done with a command like "kconfig enable > vimc". It would ask necessary questions and pull in the dependencies > automatically. Yes. That's something that it is missing for a long time. There were some efforts to add a SAT solver at the Kernel that could be used for that, but I dunno what's current status. > Twenty years ago it made sense to go through the menus and select things > one by one. Does anyone really start from defconfig any more? Surely > everyone starts with a known working config and just enables specific > options. Yeah, that's my feeling too. > I started to hack together some code to create a kconfig program to > enable and disable options. The problem is that all library code > assumes we want to display menus so it was a lot of work and I gave up. :-( Thanks, Mauro