From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 01:28:07 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C669106566B for ; Fri, 22 Aug 2008 01:28:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outs.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 71D788FC15 for ; Fri, 22 Aug 2008 01:28:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 75256242A; Thu, 21 Aug 2008 18:14:37 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 4B90A2D6085; Thu, 21 Aug 2008 18:14:36 -0700 (PDT) Message-ID: <48AE12FC.80304@elischer.org> Date: Thu, 21 Aug 2008 18:14:36 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Ed Schouten References: <20080821204736.GR99951@hoeg.nl> In-Reply-To: <20080821204736.GR99951@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: Post-MPSAFE TTY import task: fixing up line disciplines (Netgraph) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 01:28:07 -0000 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,