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.

yes, though the old interface would only call us once the 'terminator'
character was received..

you could make each calling module supply its own "decide if to call 
yet" function.. so that the heavy calls were not done every time...



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

yep

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

a nice interface to set the hardware operating parameters (e.g baud, 
bits) might be nice too but I don't know if we would use it.

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

having done this sort of hting before, the thing you want is th have 
an interface where you can pass to  the tty system, the following things:

A pointer to a number of bytes
The number of the bytes
A function to call when the tty system has finished with the buffer 
(maybe mfree())
An argument to give to that function. (probably the mbuf)

to the tty subsystem, it's a buffer of bytes
to the net system it's an mbuf.

the 4 arguments could be separately done, or they could be bundled 
together in a small structure.. your choice.


it might be overkill however if ther ewas just one byte to send, so a
way to send up to 4 bytes in one simple call might be nice...





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