On 12/01/2014 05:38 PM, Tony Lindgren wrote: > * One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx> [141201 06:11]: >>> Well the nightmare userspace switch from ttyS to ttyO few years ago is >>> something we want to avoid.. I think the best solution would be to make >>> serial-omap.c transparently provide support for ttyO using the new 8250 >>> code so both ttyS and ttyO devices would just work. Otherwise it will >>> be years of "my serial port stopped working" questions again. >> >> Thata a udev problem not a kernel one surely. > > How do you suggest we get people to update their kernel command line > and inittab? Udev may not even be installed. There are three use cases that I can think of right now: - people that enable that new driver via oldconfig I would expect that they read the help message in Kconfig. No worry about them. - people that get a complete system via magic_build_tool (may yocto or whatever) If $TOOL decides to use the new driver, then it should update commandline in bootloader. Those things create usually bootloader + kernel + rootfile system. If the commandline is saved on flash/mmc then it won't be reset from default. However udev should help here. So not a problem either (udev can't fix the kernel boot output but we should see atleast the login console). - people that build omap2plus_defconfig and we switch to the new driver Those people get switched from one driver to the other without knowing. This is what I tried to bring to everyone's attention. The defconfig hasn't been changed yet so it is not problem for next release (yet). I agree that this is a user problem. We agreed not to introduce a console proxy in kernel _or_ hack the command line in kernel (to replace O with S). So I think the problem boils down to educate the user about this change. Making the old driver disappear was one way of getting the user's attention. Another idea would be to introduce a #warning which is also activated by the defconfig and informs the user about the change. Ideally this #warning could be switched off by Kconfig once the user reads & deactivates it. This requires the pay attention to warnings during build. #error would make sure he does but it breaks auto-builds so it is not an option. > Regards, > > Tony > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
