Re: MPSAFE TTY schedule

Hello Peter,

* Peter Jeremy <peterjeremy_at_optushome.com.au> wrote:
> 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?

PTY's are deallocated when unused, which means the PTY number is reused
when possible. We still enfore the 1000 PTY limit, because utmp(5) only
supports line names of eight bytes long ("pts/999\0").

> >- 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.

Well, even though I'd rather let other people assess me, I think I've
been very proactive so far. As you can see, I sent my email to the list
two days ago. In those two days I've fixed both umodem(4) and uftdi(4)
to work with the new TTY layer again.

> >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.

Well, sio(4) isn't impossible to port to the new TTY layer, but the
first thing I noticed when I was hacking on the TTY layer during my
internship, was that the uart(4) code was so easy to read, I only had to
alter a single 396 line C file containing all the TTY interaction, while
the sio(4) was somewhat (tenfold) more complex.

But I just got told sio(4) is required for pc98, because uart(4) is not
supported there. This means I'll seriously consider porting sio(4) one
of these days. It's no biggie, even though I think someone could better
take the effort to extend uart(4).

The same with dcons(4). Even though I don't have any hardware to test it
personally, I'll try to make sure we'll get it working in time.

> 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.

So let us take a look at the list again:

> 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).

Removing the drivers which have been fixed, or will be fixed in time:

> cy(4), digi(4), ubser(4), nmdm(4), ng_h4(4), ng_tty(4), snp(4), rp(4),
> rc(4), si(4).

After I've committed the new TTY layer, I'm going to extend its design,
so we can have hooks again, similar to the old line discipline idea.
This has already been discussed. I'm also planning on reviving drivers
like nmdm(4) and snp(4) by then. This means we've only got these
drivers left:

> cy(4), digi(4), rp(4), rc(4), si(4).

Who actually owns one of these devices? If you do, please contact me. If
I didn't make myself clear enough: I *am* willing to (assist in
porting|port) these drivers.

-- 
 Ed Schouten <ed_at_80386.nl>
 WWW: http://80386.nl/