On Tue, May 02, 2006 at 03:05:02PM +0100, David Woodhouse wrote:
> On Tue, 2006-05-02 at 15:09 +0100, Alan Cox wrote:
> > There are two questions that I think make this an RFC not a final
> > patch
> >
> > 1. Should this be pushed up into serial/serial_core.c for all chips.
>
> Yes, I think it probably should. It's icky enough that we want one copy
> of it only.
That'd mean we have to add extra methods:
void uart_console_write(struct uart_port *port, const char *s,
unsigned int count,
void (*putchar)(struct uart_port *, int),
void *(*pre_write)(struct uart_port *),
void (*post_write)(struct uart_port *, void *));
where the pre-write places data into some kind of driver specific
structure which is allocated by some weird method, and post_write
restores this information.
Why are these driver specific? Review all the users of uart_console_write
and you'll find that there's many different requirements for what is
done both before and after the uart_console_write method, most of
which should arguably fall under such a lock.
And I think that calling kmalloc() from within an oops (to allocate the
memory to pass the current state between pre and post write methods)
would be very bad news.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]