From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 20:47:39 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 037171065671 for ; Thu, 21 Aug 2008 20:47:39 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3DE8FC15 for ; Thu, 21 Aug 2008 20:47:38 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 877E01CE1E; Thu, 21 Aug 2008 22:47:36 +0200 (CEST) Date: Thu, 21 Aug 2008 22:47:36 +0200 From: Ed Schouten To: net@FreeBSD.org Message-ID: <20080821204736.GR99951@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mqiO+KvAMpTa4r4+" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: 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: Thu, 21 Aug 2008 20:47:39 -0000 --mqiO+KvAMpTa4r4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. =3D=3D=3D Current design =3D=3D=3D 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 =3D { | .th_a_hook_we_like_1 =3D mydriver_foo, | .th_a_hook_we_like_2 =3D mydriver_bar, | ... | }; |=20 | static int | mydriver_ioctl(...) | { | struct tty *tp; | | switch (cmd) { | case MYDRIVER_CONNECT_TO_TTY: | error =3D ttyhook_register(&tp, td, *(int *)data, | &myhook, softc); | if (error !=3D 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. =3D=3D=3D Requirements by the NetGraph folks =3D=3D=3D 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). Yours, --=20 Ed Schouten WWW: http://80386.nl/ --mqiO+KvAMpTa4r4+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkit1GgACgkQ52SDGA2eCwXQ5QCaAoKUFH5Hkun6b+1g2AvZhBu2 /fEAni1r4zvHLsEYWCLLU8W07OFR0YoZ =SpTe -----END PGP SIGNATURE----- --mqiO+KvAMpTa4r4+--