linux-kernel - Re: [PATCH] tty: serial: serial-omap: depend on !8250

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 1 Dec 2014 09:39:33 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	linux-serial@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, Sekhar Nori <nsekhar@...com>,
	Felipe Balbi <balbi@...com>, uwe@...ine-koenig.org
Subject: Re: [PATCH] tty: serial: serial-omap: depend on !8250_omap

* Sebastian Andrzej Siewior <bigeasy@...utronix.de> [141201 09:27]:
> On 12/01/2014 05:38 PM, Tony Lindgren wrote:
> > * One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> [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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/