linux-kernel - Re: Writing a console/tty driver -- how to use tty

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 29 Oct 2010 16:21:42 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Timur Tabi <timur@...escale.com>
Cc:	gregkh <gregkh@...e.de>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: Writing a console/tty driver -- how to use tty_port?

On Thursday 28 October 2010, Timur Tabi wrote:
> Arnd Bergmann wrote:
> > If the device is not a UART, the best option may be to make the driver
> > a backend to the hvc driver, like e.g. drivers/char/hvc_tile.c.
> 
> The current version *is* a backend to hvc, but I have to abandon that because of
> this thread:
> 
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-September/085664.html
> 
> I posted a patch that causes hvc to spin if the backend driver returns -EAGAIN,
> which is my driver does when the output buffer is full.
> 
> In other words, hvc does not support backend drivers that can detect full output
> buffers.

To be more specific, hvc does support retransmitting characters on the tty
but not on the console!

The backend drivers return 0 to notify the tty driver that output is busy
and should be retried, which will set the timer.

> > This works for all devices with or without interrupts that don't need
> > to set up the communication parameters but simply provide a read/write
> > character interface.
> 
> If my patch were accepted, I wouldn't need to do the rewrite.  Dropping
> characters during a printk() is not acceptable for us.

Why do you care about printk output overflowing more than others do? Most
of the hvc drivers block internally and never return 0, but those that
do probably all need the same solution.

Your original one-line patch from last year didn't seem too wrong, though
you might want to check with the iseries people, since that driver might
return zero in error cases.

The idea of adding a special return code from ->put_chars to distinguish
buffer full from other errors also seemed reasonable, as did the approach
to flag the hv_ops to tell the base layer wether you want retransmits
or drops.

	Arnd

--
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/