Date: Thu, 21 Aug 2008 18:14:36 -0700 From: Julian Elischer <julian@elischer.org> To: Ed Schouten <ed@80386.nl> Cc: net@FreeBSD.org Subject: Re: Post-MPSAFE TTY import task: fixing up line disciplines (Netgraph) Message-ID: <48AE12FC.80304@elischer.org> In-Reply-To: <20080821204736.GR99951@hoeg.nl> References: <20080821204736.GR99951@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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@. 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,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48AE12FC.80304>