Post-MPSAFE TTY import task: fixing up line disciplines (Netgraph)

[Ed Schouten]

Hello everyone,

Before I start talking about any technical stuff, I want to mention I'm
so far pretty happy with the MPSAFE TTY import. Even though I spent a
lot of time close to my mailbox, the amount of troubles caused by the
import have remained pretty low (there's only one open bug report,
related to ucom(4)), though I'm sure I'll receive lots more the next
couple of weeks.

Today I thought it would be a good idea to work on my first post-import
task, namely designing a hooks interface, which allows other kernel
subsystems to inject/capture data. We need such an interface to
implement things like snp(4), ppp(4), sl(4), ng_h4(4) and ng_tty(4).

As an experiment, I tried to rewrite snp(4), which succeeded (though it
needs some polishing before it can hit the tree). There are actually two
things I want to discuss in this thread:

- Feedback on the current design of the hooks interface.
- Figure out which hooks we'll need. We need to know what data is
  relevant to these line disciplines.

=== Current design ===

As I said earlier, I've only got the snp(4) driver working again. A
thing I liked about the snp(4) driver, is the way it binds TTY's and
snoop instances together. There's this ioctl() called SNPSTTY which is
called on a /dev/snp descriptor, which takes a file descriptor as an
argument, pointing to the TTY.

So right now the API is as follows:

| static struct ttyhook myhook = {
| 	.th_a_hook_we_like_1	= mydriver_foo,
| 	.th_a_hook_we_like_2	= mydriver_bar,
| 	...
| };
| 
| static int
| mydriver_ioctl(...)
| {
|	struct tty *tp;
|
| 	switch (cmd) {
|	case MYDRIVER_CONNECT_TO_TTY:
|		error = ttyhook_register(&tp, td, *(int *)data,
|		    &myhook, softc);
|		if (error != 0)
|			return (error);
|	}
|	return (ENOTTY);
| }

The ttyhook_register() routine handles the filedescriptor number to TTY
translation safely, so this makes it a lot better than the old
programming interface in my opinion. When you want to disconnect the
hook, it is often as simple as:

|	tty_lock(tp);
|	ttyhook_unregister(tp);	/* This releases the lock. */

The hooks are called by the TTY layer with the per-TTY lock held. The
consumer can also store 1 pointer inside the TTY structure, which can be
obtained by calling ttyhook_softc(). A TTY can only have one associated
hook. I think in a lot of cases drivers will just borrow the TTY's lock
to lock down some private data as well.

=== Requirements by the NetGraph folks ===

So this is actually my question to the people on net at . I suspect the
NetGraph bits can be restored again if I add the following hooks to the
ttyhook interface:

- A hook which gets called each time data arrives on the device
  (`rint'). When this hook is installed, data will not be delivered to
  the actual TTY, but diverted to the subsystem in question.

- A hook which gets called when the device driver would like to have
  some data to transmit (`getc'). It just offers a buffer, which can be
  filled by the subsystem.

- A hook which notifies the subsystem of a loss of carrier, device
  disconnected, etc.

A nice thing about the new TTY layer is that we don't need to have any
horrible code to convert between mbufs and clists. You can directly copy
data from mbufs to the driver's buffers. I'll also document various
methods to implement both flow control on input and output.

So this is actually what I wanted to tell. I've already got a prototype
of the ttyhook interface stored at:

	http://people.FreeBSD.org/~ed/mpsafetty/

The diffs as of August 21 should just apply on top of SVN. It includes a
patched snp(4).

Yours,
-- 
 Ed Schouten <ed at 80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080821/bb213ce7/attachment.pgp