On 2015-09-29 18:11, Eric Curtin wrote:
Personally, I would not ever advocate not reading the help text for an option (although in some cases it's pretty un-helpful, especially for some staging drivers).On 25 September 2015 at 16:45, Austin S Hemmelgarn <ahferroin7@xxxxxxxxx> wrote:On 2015-09-25 08:02, Jiri Kosina wrote:On Fri, 25 Sep 2015, Felipe Tonello wrote:Maybe a better description on Kconfig and/or comments on source code it's enough.I personally find the current Kconfig description: === config USB_KBD tristate "USB HIDBP Keyboard (simple Boot) support" depends on USB && INPUT ---help--- Say Y here only if you are absolutely sure that you don't want to use the generic HID driver for your USB keyboard and prefer to use the keyboard in its limited Boot Protocol mode instead. This is almost certainly not what you want. This is mostly useful for embedded applications or simple keyboards. To compile this driver as a module, choose M here: the module will be called usbkbd. If even remotely unsure, say N. === shouldn't leave anyone dounting, but people are getting confused again and again nevertheless.For some reason there seem to be a lot of people who go to configure there own kernel and don't read the help text (I understand if you've been building your own Linux kernel's for years and actually understand what a Kconfig option is really asking, but most people who I've heard of doing this have never built a kernel before in their life). On the other hand, can anyone think of any real reason to use this outside of embedded systems? I know there are a lot of distros that build this and the USB HIDBP mouse support as modules, but I have yet to hear/find any reports of hardware that _only_ works with this driver and not the generic HID driver. If this is the case, it might make sense to make this depend on EXPERT or at least remove the bit about 'simple keyboards'.As regards renaming usbkbd.c, @Austin there are some reasons why you would not read the Kconfig. As a beginner, I didn't even configure this part or read the help text as I used the configuration that comes with Fedora, I don't know if that's a valid excuse or not though. I'll leave you guys decide, you're the experts! As regards the issue with my capslock led I'm still looking into it.
Your case is one of the common ones, and it's not a bad place to start, but you have to keep in mind that most distro's turn on a huge amount of stuff that more than 90% of people aren't ever going to need (for example, I'm pretty sure Ubuntu still builds a module for SLIP, which has been an essentially dead technology for more than a decade now). For anyone starting from a distro's kconfig, I'd suggest at least: a. Turn off CONFIG_EXPERT unless you intend to actually try and understand the options it enables (most distro's turn this on for some of the fine tuning features it enables, most regular people don't actually need it). b. Go through using menuconfig, and turn off stuff under the drivers menu that you know you will never need (and take the time to use stuff like lspci and lsusb to figure out what actually need). c. Read the help text before trying to change anything, and if you don't understand it after that, look it up online, and even then be careful changing it. d. If you intend on actually using it with a particular distro, don't turn off too much outside of the drivers menu, other stuff can cause things to fail in unusual ways, and you often won't get a great amount of help from the distro maintainers when using a custom kernel.
The real problem is when people just read the option name and think they understand it when they don't really (or just don't think about the implications), and then wonder why something stops working suddenly (like one guy I know who was building a kernel for a server, and thought he could just disable everything under the 'Graphics' menu, then wondered why he didn't get console output on his monitor).
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
