Messages in this thread | | | Date | Tue, 21 Oct 2008 20:54:23 -0500 | From | Jason Wessel <> | Subject | Re: [PATCH 5/7] kgdboc, tty: use tty open to start low level drivers |
| |
Alan Cox wrote: > 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?
> 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.
> > 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.
| |