Re: MPSAFE TTY schedule

On 2008-Jul-02 21:09:01 +0200, Ed Schouten <ed_at_80386.nl> wrote:
>+ The new pseudo-terminal driver is capable of garbage collecting unused
>  PTY's. Because PTY's are never recycled, they are a lot more robust
>  (they are always initialized the same, no need to revoke() them before
>  usage, etc).

When you say 'never recycled', does this include the PTY number?  If
so, long running busy systems are going to get some fairly large
numbers.  When will the PTY number wrap?  What is the impact on tools
(eg ps, w) that assume they can represent a PTY in a small number of
digits?  What about utmp(5) which uses PTY number in the index?

>- Not all drivers have been ported to the new TTY layer yet. These
>  drivers still need to be ported: sio(4), cy(4), digi(4), ubser(4),
>  uftdi(4), nmdm(4), ng_h4(4), ng_tty(4), snp(4), rp(4), rc(4), si(4),
>  umodem(4), dcons(4).
>
>Even though drivers are very important to have, I am convinced we can
>get these working not long after the code as been integrated. ...
> If you really care about one of these drivers,
>please port it to the new TTY layer as soon as possible!

IMHO, this is not a reasonable approach: "Hi everyone.  I'm going to
break infrastructure that a whole bunch of drivers depend on.  If you
don't fix your drivers in the next few weeks then I'll disconnect
them".  Either you need to provide compatibility shims (possibly
temporary and not MPSAFE) or you need to be far more pro-active in
assisting with porting existing consumers of the TTY layer.

>TTY layer into our kernel. I would really appreciate it if I could get
>this code in before the end of the summer break, because I've got heaps
>of spare time to fix any problems then.

That's all very nice but what about the maintainers of all the other
drivers that you are impacting?

>	sio(4) has not been ported to the new TTY layer and is very hard
>	to do so.

This is the only mention of how much effort is involved in porting a
driver to use the MPSAFE TTY layer and "very hard" is not a good start.
I can't quickly find any documentation on how to go about porting an
existing driver - definitely there are no section 9 man pages describing
the new API in your patchset.

IMHO, if you can't commit fixed drivers along with the MPSAFE TTY
layer, a more reasonable schedule is to replace the existing TTY layer
with an MPSAFE TTY layer that includes compatibility shims.  If the
shims make things non-MPSAFE (which is likely) then warn that they
will be going away in (say) six months.  This gives developers a more
reasonable timeframe in which to update, as well as working drivers
whilst they adapt them.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.