linux-kernel - Re: [PATCH] Provide better abstraction for the serial drivers to xmit buf and 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:	Wed, 18 Apr 2007 11:15:39 -0500
From:	Corey Minyard <minyard@....org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH] Provide better abstraction for the serial drivers to
 xmit buf and tty

Alan Cox wrote:
>> The basic reason for all this is to eventually allow the low-level
>> serial drivers to function without a uart_info structure being
>> allocated.  This will allow the serial console, debuggers like kgdb,
>> and the IPMI serial driver to use one interface to the uart code and
>>     
>
> Its cheaper to allocate a uart_info that keep doing all the checks, at
> least for port->info. I can see why you want to avoid port->info->tty as
> a debugger can end up running before the tty layer and that would be hard
> to work around.
>   
Currently the uart_info structure is allocated on an open, so it's not
available until that point in time.  The trouble is that console_init() is
called before memory is set up, so you can't allocate the uart_info
until it's too late for the console or a debugger that wants to work
early, though it's ok for IPMI.
> For the other macros - the macros are more efficient than the equivalent
> inline code generation at least for some gccs.
>   
I thought that inlines were preferred, but I can do macros.
> Do you really need any of this change but to check info->tty ?
>   
I'm not really sure.  For IPMI I could do without it, but I'm not
sure about consoles or debuggers.

I have a patch that does consoles over this.  Part of that is moving
the transmit (circ) buffer to the port, so that port->info is not required
at all for console I/O and the console code can supply its own transmit
buffer.  This allows the polled I/O code to reuse all the standard uart
operations for the low-level driver and for the user code, just having
to add a function to call the interrupt handlers properly.

The uart_info struct is not very big, maybe it would be best to pull that
into uart_port?  But the circ buffer might still be a problem, since it
would need to be dynamically allocated and it might need to be
checked instead.

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