Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 3 Apr 2019 16:11:09 +0200
From:   Vincent Whitchurch <vincent.whitchurch@axis.com>
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     jslaby@suse.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tty: Add NULL TTY driver
Message-ID: <20190403141109.3mdmqbt3mjxrie6k@axis.com>
References: <20190403113327.3628-1-vincent.whitchurch@axis.com>
 <20190403131213.GA4246@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190403131213.GA4246@kroah.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Apr 03, 2019 at 03:12:13PM +0200, Greg KH wrote:
> On Wed, Apr 03, 2019 at 01:33:27PM +0200, Vincent Whitchurch wrote:
> > If no console driver is enabled (or if a non-present driver is selected
> > with something like console=null in an attempt to disable the console),
> > opening /dev/console errors out, and init scripts and other userspace
> > code that relies on the existence of a console will fail.  Symlinking
> > /dev/null to /dev/console does not solve the problem since /dev/null
> > does not behave like a real TTY.
> > 
> > To just provide a dummy console to userspace when no console driver is
> > available or desired, add a ttynull driver which simply discards all
> > writes.  It can be chosen on the command line in the standard way, i.e.
> > with console=ttynull.
> 
> If they have a broken system that sets "console=null", why would they
> know to fix it to be "console=ttynull"?
> 
> I'm all for adding new functionality, but to provide kernel code because
> userspace just isn't configured properly, that feels really wrong to me.

Especially on embedded systems, it would be convenient to have a simple
way to disable the console (both for kernel and userspace) on a system
which normally uses it, to free up the UART for other things.

In my case some early init script in userspace was actually tring to
handle the lack of a console in this way:

 [ ! -w /dev/console ] || exec 2>/dev/console

but the problem is that /dev/console always exists but fails on write,
so the obvious way of handling missing devices doesn't work.  AFAICS the
only way to get rid of /dev/console would be to disable the TTY layer
entirely in the kernel or have early userspace delete the file from
devtmpfs.

> Now if this were to be the "default" if nothing is set up at all, that
> might make a bit more sense, but as-is, this doesn't seem very useful.

Making it the default now would break users, wouldn't it?  Since IIRC if
no console is selected, the first registered console will automatically
be used by default.