Re: tty's use of file_list_lock and file_move

["Jon Smirl" <jonsmirl@gmail.com>]

On 7/11/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Ar Maw, 2006-07-11 am 18:08 -0400, ysgrifennodd Jon Smirl:
> > What about adjusting things so the BKL isn't required? I tried
> > completely removing it and died in release_dev. tty_mutex is already
> > locks a lot of stuff, maybe it can be adjusted to allow removal of the
> > BKL.
>
> Thats what is happening currently. However it is being done piece by
> piece, slowly and carefully.
>
> > I see why no one works on this code, it is very intertwined with the
> > rest of the kernel and a lot of the reasons for locking are
> > non-obvious.
>
> You should follow l/k more closely. Since 2.6.15 Paul Fulghum and I have
> completely rewritten the entire buffering logic. In 2.6.14 or so I
> rewrote the line discipline locking and support code.

I had noticed that code looked new and quite clean, I have not seen
any problems with it.

> One hint by the way - stop looking at locks and code, look at locks and
> data structures. There is an old saying "lock data not code" and it
> really is true if you want to follow the locking and get it right.
>
> The open/close/hangup logic is last on the list to fix, because as
> you've noticed its the most horrible. Once the other locking is sane
> that bit should become more managable even with the strict and bizarre
> rules POSIX and SuS enforce on us in this area.

My original goal was to do some work on the VT layer but I got sucked
into the TTY code because of VT/TTY interactions. I think I understand
enough now that I can make changes in the VT code without breaking
everything. I also see now that the VT code wasn't as closely
intertwined into the TTY code as much as I initially thought it was.

So getting back to my VT problem, I want to fully decouple the VT code
from the TTY code. By decoupling I mean make the VT code use APIs and
not have #ifdef CONFIG_VT sprinkled all over the place. There are
fifteen #ifdef CONFIG_VT's is general kernel code and about twenty
more in arch specific code.

One #ifdef CONFIG_VT is in tty_init().  The tty layer is being
initialized via module_init(tty_init) which is the same as
device_initcall(fn).  Link order is pci, video, acpi, char, serial,
base. This doesn't look right to me since the video console drivers
need the tty code to function.

This may also explain why the init functions are all chained together.
tty_init() -> vty_init() -> vcs_init(), kbd_init(), prom_con_init(),
etc... Since the link order is wrong the chained init functions are
compensating.

The fix for this is to get things linking in the right order, add
module_init() where needed then all of the chained init()'s can be
removed.

--
Jon Smirl
jonsmirl@gmail.com
-
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/