Alan Cox wrote:
quoted text
> On Tue, 21 Oct 2008 14:14:51 -0500
> Jason Wessel <jason.wessel@windriver.com> wrote:
>
>> +        unlock_kernel();
>> +    } else {
>> +        tty = tty_driver_lookup_tty(driver, NULL, tty_line);
>> +        if (!tty) {
>> +            tty = tty_init_dev(driver, tty_line, 0);
>> +            inc_tty = 0;
>> +        }
>> +        (*filp)->private_data = tty;
>> +        ret = tty->ops->open(tty, *filp);
>
> and with the error paths wrong
>
>
> This is to put it bluntly just horrible.
>

Yeah, I'd say it is pretty horrible too, but this the only API that
exists presently and it is not at all obvious how to use it.

I am fine with keeping it out of the tree, IE this patch is dropped
from merge consideration for now.  It is obvious that it is a moving
target because the patch to 2.6.27 looked different than 2.6.28.  Even
with it out of the tree I am interested in fixing the "error paths"
you mentioned.  Perhaps in this case the return of tty_init_dev()
needed further checking and that was what you were stating is incorrect?

quoted text
> Really kgdb, console and other boot processes need an abstraction for tty
> device ports at the device (not ldisc) level and until that work is done
> there is no acceptable way to sort this out. Merging gunk like this will
> simply make the existing mess worse and provide more crap that will make
> it harder to fix properly.

If there is another API, please point me to it.  I am not aware of how
to get uart startup code to run without going through the
tty->ops->open().  The kgdboc module has only a generic high level
interface and makes use of only the high level tty calls.  The
debugger's needs are the same as the console and the user space.  The
early debug is still a special case, but in the ideal world there
would be a way to hand off from early debug into the struct tty_port
at the point that console_init() is called.

quoted text
>
> All this stuff needs revisiting when every tty device side object in the
> kernel contains a struct tty_port, until then it's a nasty (perhaps
> neccessary for the moment) hack that belongs out of tree.

Let me know when we get closer to that stage, as I am interested in
figuring out how to have a uniform way to share the hardware between
the polled and interrupt drive contexts.

Thanks,
Jason.

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/