MPSAFE TTY layer - Testers? Reviews?

Hello everyone,

I hope almost everyone by now knows I'm working on a new MPSAFE TTY
layer for our FreeBSD kernel. A lot has happened since I started hacking
(14 Feb). Right now my TTY layer is quite functional. There are still
some things that are missing, but I think it's very realistic to have
this in the base system before 8.0-RELEASE.

This is my first public Call for {Testers,Reviews}. To be precise, I'm
interested in a couple of things:

- "Works for me"'s. The code should be quite robust, but it's possible I
  missed a thing or two. I would really appreciate it if I could get
  some other people to test this code. So far, all my applications work
  like they should, but you can't be too sure.

- Feedback on the overall design of the TTY layer - the `high level'
  stuff.

- Feedback on the smaller details of the code. style(9), logical errors,
  you name it.

- Patches for drivers that still need to be ported. There are still some
  drivers that I haven't ported to the new TTY layer, mainly because I
  don't own the actual hardware.

The patchset I've developed is available at the following location. The
file at the bottom is the latest version. It should survive `make
universe', except for the sun4v and ia64 architectures. Be sure to boot
the new kernel before running `make installworld'.

	http://www.il.fontys.nl/~ed/projects/mpsafetty/patches/

Below is a list of TODO items:

- The sio(4), cy(4), digi(4), ubser(4), uftdi(4), nmdm(4), ng_h4(4),
  ng_tty(4), sl(4), ppp(4), snp(4), rp(4), rc(4), si(4), umodem(4),
  dcons(4), IA64 SKI console driver and Sun4V console driver have not
  been ported yet. ucom(4) also needs to be polished. sio(4) should be
  replaced by uart(4). Help wanted.

- There is no `zombie state' yet; when a disconnect occurs, proper
  signals are set the session leader, but according to POSIX, we should
  return 0 byte read()'s then. Support for IXOFF is also missing.

- The manual pages are not up-to-date.

- PTY's `packet mode' still has to be implemented properly.

- The new TTY layer provides a fallback mechanism to allow drivers that
  use Giant to still work. I had to make some changes to kern_mutex.c,
  to allow condvar(9) to work with Giant, but this is not ideal. Any
  ideas here?

It would be foolish if I would ask people to review this code, without
actually giving a little background:

One of the (in my opinion) bad things about the existing TTY code, is
that it is not a front-end for device drivers. Many drivers create the
TTY device nodes themselves, implement their own cdev routines, etc. My
MPSAFE TTY layer only allows device nodes to be created through the TTY
layer itself. This means each TTY created by the TTY layer implements a
generic behaviour to user processes. Even the PTY driver is no more
different than any other driver. All drivers just supply a structure
with hooks (struct ttydevsw).

Another important structures inside the TTY layer are `ttyinq' and
`ttyoutq'. Unlike the existing code, this TTY layer does not use clists
to store data. The advantage here is that these queues are better
tailored to our requirements. Both queues support unbuffered copying
back to userspace, O(1) line termination, etc.

I've also rewritten the PTY drivers. We now have two drivers, pts(4) and
ptycompat(4). The first driver implements UNIX98 PTY device names
(/dev/pts/%u), while ptycompat(4) supports the traditional device
naming. The pts(4) driver is compatible with FreeBSD -CURRENT and Linux
binaries, while the ptycompat(4) driver should be uses with RELENG_7 and
older. PTY's should be removed from the system properly. This means
pstat(8) whill now only show PTY's that are actually being used.

If there are any more questions, I would be happy to answer them. I
think it would be great if we could eventually get this integrated. This
will make it possible to make a lot more drivers MPSAFE (i.e. the input
layer).

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