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 <ed80386.nl>
 WWW: http://80386.nl/