linux-kernel - Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial

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]

Message-ID: <20151112195707.5e9cb1d8@lxorguk.ukuu.org.uk>
Date:	Thu, 12 Nov 2015 19:57:07 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	"Matwey V. Kornilov" <matwey@....msu.ru>
Cc:	gregkh@...uxfoundation.org, jslaby@...e.com,
	peter@...leysoftware.com, linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag
 for struct serial_rs485

On Thu, 12 Nov 2015 17:33:53 +0300
"Matwey V. Kornilov" <matwey@....msu.ru> wrote:

> This flag is supposed to be used by uart drivers using software rs485 direction control.
> 
> Signed-off-by: Matwey V. Kornilov <matwey@....msu.ru>
> ---
>  include/uapi/linux/serial.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/uapi/linux/serial.h b/include/uapi/linux/serial.h
> index 25331f9..95b15ca 100644
> --- a/include/uapi/linux/serial.h
> +++ b/include/uapi/linux/serial.h
> @@ -121,6 +121,9 @@ struct serial_rs485 {
>  #define SER_RS485_RTS_AFTER_SEND	(1 << 2)	/* Logical level for
>  							   RTS pin after sent*/
>  #define SER_RS485_RX_DURING_TX		(1 << 4)
> +#define SER_RS485_SOFTWARE		(1 << 5)	/* Software
> +							   implementation is
> +							   being used */

I've only got one question here - why do we need this flag. Why does the
application care whether the timer is in the kernel or in the chip. In
particular think about cases where some combinations of features require
software fallback and others don't. What would the flag indicate then.

The patches look nice but I'd strongly favour not having a software flag.
It should never matter as the kernel API is the same in all cases and we
should therefore discourage application code from trying to know things
it doesn't need to worry about.

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