TTY layer locking design

TTY layer locking design

[Blaisorblade]

I've started cleaning up locking in UML TTY drivers, and I've found some 
difficulties in making it work cleanly.

I was starting looking well into the TTY layer locking and its design, and at 
a first (and carent) look I found it difficult to follow; recent changes to 
tty refcounting seem to point out that much work needs to be done, as one can 
guess after looking at the code (I wasn't sure whether the problem was on the 
code or on the reader ;-), however).

So I have some questions before starting really to delve here:

*) who is maintaining this aspect of code ? The only name found in MAINTAINERS 
and CREDITS is the one of James Simmons.
*) would the locking need to be redesigned?
*) is the current design reputed solid? I'm not only talking about the big 
kernel lock, but also about whether drivers need to reinvent (incorrectly) 
the wheel for their locking. UML drivers are very bad on this, but I've found 
difficulty both at reading the code and at finding documentation.
*) Documentation/tty.txt is quite carent.

*) there is no generic way to handle tty's which are also consoles, except 
drivers/char/vt.c - that code is written as if it were the only case where 
that applies. Instead, UML drivers are an exception to this - UML cannot use 
virtual terminals.
Having a generic console driver using tty methods appears to be a cleaner 
design (think, in filesystem writing, of page cache methods based 
on ->readpage and ->writepage).

I'm trying to establish whether it is possible, for instance, for ->close to 
be called in parallel to ->write and such; in other driver layer this is 
impossible because refcounts are used (normal files, char & block devices) 
or, in the network layer, where refcount usage is impossible, because of 
state machines (in the network layer).

It seems not to happen for the console layer - is this true?
Also, since write must use a spinlock because it must protect from interrupt 
races, and open cannot, must we use both a mutex and a spinlock in ->write 
and similar methods? This can be avoided in other drivers.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade

 
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 

Re: TTY layer locking design

[Alan Cox]

On Sat, Nov 18, 2006 at 12:11:38AM +0200, Blaisorblade wrote:
> *) who is maintaining this aspect of code ? The only name found in MAINTAINERS 
> and CREDITS is the one of James Simmons.

There is no one maintainer. I did some of the documentation and buffering
abstraction. Paul Fulghum wrote the SMP aware and clever locking bits
for the buffer handling. Since then other people have worked on the 
reference locking and the current->tty races and fixed those
 
> *) is the current design reputed solid? I'm not only talking about the big 
> kernel lock, but also about whether drivers need to reinvent (incorrectly) 
> the wheel for their locking. UML drivers are very bad on this, but I've found 
> difficulty both at reading the code and at finding documentation.

As of 2.6.19-rc I think the majority of the big issues are sorted

> *) there is no generic way to handle tty's which are also consoles, except 
> drivers/char/vt.c - that code is written as if it were the only case where 
> that applies. Instead, UML drivers are an exception to this - UML cannot use 
> virtual terminals.

Untrue - many serial drivers support being consoles

> I'm trying to establish whether it is possible, for instance, for ->close to 
> be called in parallel to ->write and such; in other driver layer this is 

Close/Write cannot occur in parallel. The VFS guarantees this

> Also, since write must use a spinlock because it must protect from interrupt 
> races, and open cannot, must we use both a mutex and a spinlock in ->write 
> and similar methods? This can be avoided in other drivers.

See the existing drivers. Open can use spinlocks