* Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> [141201 09:27]: > 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. The problem is the kernel will just mysteriously stop outputting anything if we enable the new driver. This is a "flag day" type problem that needs the user to somehow coordinate the kernel version, kernel .config, kernel cmdline, dev entries, and the inittab. Regards, Tony -- 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
