linux-kernel - Re: [PATCH 3/3] usb console,usb-serial: pass initial console baud on to first tty open

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: <4AB1B860.4080105@windriver.com>
Date:	Wed, 16 Sep 2009 23:17:36 -0500
From:	Jason Wessel <jason.wessel@...driver.com>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	gregkh@...e.de, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] usb console,usb-serial: pass initial console baud
 on to first tty open

Alan Stern wrote:
> On Wed, 16 Sep 2009, Jason Wessel wrote:
>
>   
>> Alan Stern wrote:
>>     
>>> On Wed, 16 Sep 2009, Jason Wessel wrote:
>>>
>>>   
>>>       
>>>> The first open of the usb serial HW has the termios initialized to the
>>>> default of 9600 baud, and this will override what ever was setup via
>>>> the original console initialization.
>>>>     
>>>>         
>>> I don't understand.  The first open of the console hardware occurs in 
>>> console.c as part of usb_console_setup(), and it uses the baud rate 
>>> passed in via the console options.  Why does anything need to get 
>>> saved?
>>>   
>>>       
>> The initialization in console.c is done with a dummy tty structure that
>> is thrown away.  It is thrown away because it was not connected to any
>> device handle.
>>
>> Any new tty that is opened defaults to 9600 baud, for the mct_u232
>> driver as an example, if you boot the system with
>> console=ttyUSB0,115200, when mingetty starts it will inherit 9600 from
>> the first tty that is opened, vs reading the value from the HW.  Even if
>> you have a pl2303 and boot with the 115200 baud, you can run "stty -a <
>> /dev/ttyUSB0" and you will see it reports it is running at 9600.  The
>> pl2303 driver just happens to work because it handles the baud differently.
>>
>> I elected to save the baud because:
>>
>> 1) There was no uniform interface to read the current baud from the usb
>> hardware
>>
>> 2) There was no documented API for getting tty to attach when you create
>> the initial console.
>>
>> If there is a better way to fix this, it would be good to continue the
>> discussion.
>>     
>
> I guess a better approach would be not to throw away the "dummy" tty 
> structure, thereby keeping the termios structure as well.  But I don't 
> know if this is practical.
>
> How do other serial console drivers handle this?
>
>   

My answer goes back to the point #1.

If we take the 8250 driver for example,  it reads the HW and force sets
the baud into the termios structure of the real tty.   There are several
layers but in the example case in 8250.c, the serial8250_set_termios()
calls uart_get_baud_rate() to establish "the baud rate to use".

As far as I could tell even the uart based serial drivers use a dummy
termios structure for the initial setup of the console, but do so with
stack memory instead of heap memory.

It looked like the API for the tty subsystem was gradually changing such
that the ldisc structure could ultimately get shared for use with the
console, but this work is not complete, so we are somewhere in between.

The question is what is an acceptable solution?

Depending on the route you go you could modify part of the tty
subsystem, the high level usb serial API to work similarly to the uart
based serial api.

Jason.

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