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

[Julian Elischer]

Ed Schouten wrote:
> 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).

got a p4 pointer?

> 
> Yours,