d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
c80b5ef285
freebsd-nq/sys/dev/nmdm/nmdm.c

347 lines
8.1 KiB
C
Raw Normal View History

Start each of the license/copyright comments with /*-, minor shuffle of lines
2005-01-06 01:43:34 +00:00
/*-
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
* Copyright (c) 1982, 1986, 1989, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*/
Use __FBSDID(). Also some minor style cleanups.
2003-08-24 17:55:58 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
/*
Cleanup of nmdm device
2002-02-20 20:13:13 +00:00
* Pseudo-nulmodem driver
* Mighty handy for use with serial console in Vmware
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
*/
Cleanup of nmdm device
2002-02-20 20:13:13 +00:00
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
#include "opt_compat.h"
Make TTYHOG tunable. Reviewed by: mike (mentor)
2003-03-05 08:16:29 +00:00
#include "opt_tty.h"
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/proc.h>
#include <sys/tty.h>
#include <sys/conf.h>
#include <sys/fcntl.h>
#include <sys/poll.h>
#include <sys/kernel.h>
Add missing <sys/module.h> includes
2004-05-30 20:08:47 +00:00
#include <sys/module.h>
Add modemcontrol support for DTR and DCD. Tested by: ambrisko
2004-07-04 16:27:58 +00:00
#include <sys/serial.h>
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
#include <sys/signalvar.h>
#include <sys/malloc.h>
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
#include <sys/taskqueue.h>
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
MALLOC_DEFINE(M_NLMDM, "nullmodem", "nullmodem data structures");
Cleanup of nmdm device
2002-02-20 20:13:13 +00:00
static void nmdmstart(struct tty *tp);
static void nmdmstop(struct tty *tp, int rw);
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
static void nmdminit(struct cdev *dev);
Add modemcontrol support for DTR and DCD. Tested by: ambrisko
2004-07-04 16:27:58 +00:00
static t_modem_t nmdmmodem;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
Cleanup of nmdm device
2002-02-20 20:13:13 +00:00
static d_open_t nmdmopen;
static d_close_t nmdmclose;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
static struct cdevsw nmdm_cdevsw = {
Device megapatch 4/6: Introduce d_version field in struct cdevsw, this must always be initialized to D_VERSION. Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
2004-02-21 21:10:55 +00:00
.d_version = D_VERSION,
Gigacommit to improve device-driver source compatibility between branches: Initialize struct cdevsw using C99 sparse initializtion and remove all initializations to default values. This patch is automatically generated and has been tested by compiling LINT with all the fields in struct cdevsw in reverse order on alpha, sparc64 and i386. Approved by: re(scottl)
2003-03-03 12:15:54 +00:00
.d_open = nmdmopen,
.d_close = nmdmclose,
Device megapatch 4/6: Introduce d_version field in struct cdevsw, this must always be initialized to D_VERSION. Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
2004-02-21 21:10:55 +00:00
.d_name = "nmdn",
.d_flags = D_TTY | D_PSEUDO | D_NEEDGIANT,
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
};
Cleanup of nmdm device
2002-02-20 20:13:13 +00:00
#define BUFSIZ 100 /* Chunk size iomoved to/from user */
#define NMDM_MAX_NUM 128 /* Artificially limit # devices. */
#define PF_STOPPED 0x10 /* user told stopped */
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
#define BFLAG CLONE_FLAG0
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
struct softpart {
Add modemcontrol support for DTR and DCD. Tested by: ambrisko
2004-07-04 16:27:58 +00:00
struct tty *nm_tty;
struct cdev *dev;
int nm_dcd;
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
struct task pt_task;
struct softpart *other;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
};
struct nm_softc {
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
TAILQ_ENTRY(nm_softc) pt_list;
int pt_flags;
struct softpart part1, part2;
struct prison *pt_prison;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
};
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
static struct clonedevs *nmdmclones;
static TAILQ_HEAD(,nm_softc) nmdmhead = TAILQ_HEAD_INITIALIZER(nmdmhead);
static void
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
nmdm_clone(void *arg, char *name, int nameen, struct cdev **dev)
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
{
int i, unit;
char *p;
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
struct cdev *d1, *d2;
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
Second half of the dev_t cleanup. The big lines are: NODEV -> NULL NOUDEV -> NODEV udev_t -> dev_t udev2dev() -> findcdev() Various minor adjustments including handling of userland access to kernel space struct cdev etc.
2004-06-17 17:16:53 +00:00
if (*dev != NULL)
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
return;
if (strcmp(name, "nmdm") == 0) {
p = NULL;
unit = -1;
} else {
i = dev_stdclone(name, &p, "nmdm", &unit);
if (i == 0)
return;
if (p[0] != '\0' && p[0] != 'A' && p[0] != 'B')
return;
else if (p[0] != '\0' && p[1] != '\0')
return;
}
i = clone_create(&nmdmclones, &nmdm_cdevsw, &unit, &d1, 0);
if (i) {
d1 = make_dev(&nmdm_cdevsw, unit2minor(unit),
0, 0, 0666, "nmdm%dA", unit);
if (d1 == NULL)
return;
d2 = make_dev(&nmdm_cdevsw, unit2minor(unit) | BFLAG,
0, 0, 0666, "nmdm%dB", unit);
if (d2 == NULL) {
destroy_dev(d1);
return;
}
d2->si_drv2 = d1;
d1->si_drv2 = d2;
dev_depends(d1, d2);
dev_depends(d2, d1);
d1->si_flags |= SI_CHEAPCLONE;
d2->si_flags |= SI_CHEAPCLONE;
}
if (p != NULL && p[0] == 'B')
*dev = d1->si_drv2;
else
*dev = d1;
}
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
static void
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
nmdm_task_tty(void *arg, int pending __unused)
{
struct tty *tp, *otp;
struct softpart *sp;
int c;
tp = arg;
sp = tp->t_sc;
otp = sp->other->nm_tty;
KASSERT(otp != NULL, ("NULL otp in nmdmstart"));
KASSERT(otp != tp, ("NULL otp == tp nmdmstart"));
Add modemcontrol support for DTR and DCD. Tested by: ambrisko
2004-07-04 16:27:58 +00:00
if (sp->other->nm_dcd) {
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
if (!(tp->t_state & TS_ISOPEN)) {
Add modemcontrol support for DTR and DCD. Tested by: ambrisko
2004-07-04 16:27:58 +00:00
sp->other->nm_dcd = 0;
Machine generated patch which changes linedisc calls from accessing linesw[] directly to using the ttyld...() functions The ttyld...() functions ar inline so there is no performance hit.
2004-06-04 16:02:56 +00:00
(void)ttyld_modem(otp, 0);
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
}
} else {
if (tp->t_state & TS_ISOPEN) {
Add modemcontrol support for DTR and DCD. Tested by: ambrisko
2004-07-04 16:27:58 +00:00
sp->other->nm_dcd = 1;
Machine generated patch which changes linedisc calls from accessing linesw[] directly to using the ttyld...() functions The ttyld...() functions ar inline so there is no performance hit.
2004-06-04 16:02:56 +00:00
(void)ttyld_modem(otp, 1);
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
}
}
if (tp->t_state & TS_TTSTOP)
return;
while (tp->t_outq.c_cc != 0) {
if (otp->t_state & TS_TBLOCK)
return;
c = getc(&tp->t_outq);
if (otp->t_state & TS_ISOPEN)
Machine generated patch which changes linedisc calls from accessing linesw[] directly to using the ttyld...() functions The ttyld...() functions ar inline so there is no performance hit.
2004-06-04 16:02:56 +00:00
ttyld_rint(otp, c);
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
}
if (tp->t_outq.c_cc == 0)
ttwwakeup(tp);
}
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
/*
* This function creates and initializes a pair of ttys.
*/
static void
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
nmdminit(struct cdev *dev1)
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
{
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
struct cdev *dev2;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
struct nm_softc *pt;
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
dev2 = dev1->si_drv2;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
dev1->si_flags &= ~SI_CHEAPCLONE;
dev2->si_flags &= ~SI_CHEAPCLONE;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
pt = malloc(sizeof(*pt), M_NLMDM, M_WAITOK | M_ZERO);
TAILQ_INSERT_TAIL(&nmdmhead, pt, pt_list);
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
dev1->si_drv1 = dev2->si_drv1 = pt;
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
pt->part1.dev = dev1;
pt->part2.dev = dev2;
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
pt->part1.nm_tty = ttymalloc(pt->part1.nm_tty);
pt->part1.nm_tty->t_oproc = nmdmstart;
pt->part1.nm_tty->t_stop = nmdmstop;
Add modemcontrol support for DTR and DCD. Tested by: ambrisko
2004-07-04 16:27:58 +00:00
pt->part1.nm_tty->t_modem = nmdmmodem;
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
pt->part1.nm_tty->t_dev = dev1;
pt->part1.nm_tty->t_sc = &pt->part1;
TASK_INIT(&pt->part1.pt_task, 0, nmdm_task_tty, pt->part1.nm_tty);
pt->part2.nm_tty = ttymalloc(pt->part2.nm_tty);
pt->part2.nm_tty->t_oproc = nmdmstart;
pt->part2.nm_tty->t_stop = nmdmstop;
Add modemcontrol support for DTR and DCD. Tested by: ambrisko
2004-07-04 16:27:58 +00:00
pt->part2.nm_tty->t_modem = nmdmmodem;
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
pt->part2.nm_tty->t_dev = dev2;
pt->part2.nm_tty->t_sc = &pt->part2;
TASK_INIT(&pt->part2.pt_task, 0, nmdm_task_tty, pt->part2.nm_tty);
pt->part1.other = &pt->part2;
pt->part2.other = &pt->part1;
dev1->si_tty = pt->part1.nm_tty;
dev1->si_drv1 = pt;
dev2->si_tty = pt->part2.nm_tty;
dev2->si_drv1 = pt;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
}
Cleanup of nmdm device
2002-02-20 20:13:13 +00:00
/*
* Device opened from userland
*/
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
static int
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
nmdmopen(struct cdev *dev, int flag, int devtype, struct thread *td)
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
{
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
struct tty *tp, *tp2;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
int error;
struct nm_softc *pti;
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
struct softpart *sp;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
if (dev->si_drv1 == NULL)
nmdminit(dev);
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
pti = dev->si_drv1;
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
if (pti->pt_prison != td->td_ucred->cr_prison)
return (EBUSY);
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
tp = dev->si_tty;
sp = tp->t_sc;
tp2 = sp->other->nm_tty;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
if ((tp->t_state & TS_ISOPEN) == 0) {
Add new function ttyinitmode() which sets our systemwide default modes on a tty structure. Both the ".init" and the current settings are initialized allowing the function to be used both at attach and open time. The function takes an argument to decide if echoing should be enabled. Echoing should not be enabled for regular physical serial ports unless they are consoles, in which case they should be configured by ttyconsolemode() instead. Use the new function throughout.
2004-10-18 21:51:27 +00:00
ttyinitmode(tp, 0, 0);
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
ttsetwater(tp); /* XXX ? */
Change the suser() API to take advantage of td_ucred as well as do a general cleanup of the API. The entire API now consists of two functions similar to the pre-KSE API. The suser() function takes a thread pointer as its only argument. The td_ucred member of this thread must be valid so the only valid thread pointers are curthread and a few kernel threads such as thread0. The suser_cred() function takes a pointer to a struct ucred as its first argument and an integer flag as its second argument. The flag is currently only used for the PRISON_ROOT flag. Discussed on: smp@
2002-04-01 21:31:13 +00:00
} else if (tp->t_state & TS_XCLUDE && suser(td)) {
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
return (EBUSY);
}
Machine generated patch which changes linedisc calls from accessing linesw[] directly to using the ttyld...() functions The ttyld...() functions ar inline so there is no performance hit.
2004-06-04 16:02:56 +00:00
error = ttyld_open(tp, dev);
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
return (error);
}
Add modemcontrol support for DTR and DCD. Tested by: ambrisko
2004-07-04 16:27:58 +00:00
static int
nmdmmodem(struct tty *tp, int sigon, int sigoff)
{
struct softpart *sp;
int i;
sp = tp->t_sc;
if (sigon || sigoff) {
if (sigon & SER_DTR) {
sp->other->nm_dcd = 1;
ttyld_modem(sp->other->nm_tty, sp->other->nm_dcd);
}
if (sigoff & SER_DTR) {
sp->other->nm_dcd = 0;
ttyld_modem(sp->other->nm_tty, sp->other->nm_dcd);
}
return (0);
} else {
i = 0;
if (sp->nm_dcd)
i |= SER_DCD;
if (sp->other->nm_dcd)
i |= SER_DTR;
return (i);
}
}
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
static int
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
nmdmclose(struct cdev *dev, int flag, int mode, struct thread *td)
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
{
Preparation commit for the tty cleanups that will follow in the near future: rename ttyopen() -> tty_open() and ttyclose() -> tty_close(). We need the ttyopen() and ttyclose() for the new generic cdevsw functions for tty devices in order to have consistent naming.
2004-07-15 20:47:41 +00:00
return (tty_close(dev->si_tty));
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
}
static void
Cleanup of nmdm device
2002-02-20 20:13:13 +00:00
nmdmstart(struct tty *tp)
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
{
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
struct softpart *pt;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
pt = tp->t_sc;
taskqueue_enqueue(taskqueue_swi_giant, &pt->pt_task);
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
}
static void
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
nmdmstop(struct tty *tp, int flush)
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
{
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
struct softpart *pt;
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
A major overhaul of the nmdm(4) driver: It was based on the pty(4) driver which as a tty side an a non-tty side. Nmdm(4) seems to have inherited two symmetric sides from pty but unfortunately they are not quite ttys. Running a getty one one side and tip on the other failed to produce NL->CRNL mapping for instance. Rip out the basically bogus cdevsw->{read,write} functions and rely on ttyread() and ttywrite() which does the same thing. Use taskqueue_swi_giant to run a task for either side to do what needs to be done. (Direct calling is not an option as it leads to recursion.) Trigger the task from the t_oproc and t_stop methods. Default the ports to not ECHO. Since we neither rate limiting nor emulation, two ports echoing each other is a really bad idea, which can only be properly mitigated by rate limiting, rate emulation or intelligent detection. Rate emulation would be a neat feature. Ditch the modem-line emulation, if needed for some app, it needs to be thought much more about how it interacts with the open/close logic.
2004-06-01 22:53:00 +00:00
pt = tp->t_sc;
taskqueue_enqueue(taskqueue_swi_giant, &pt->pt_task);
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
}
Cleanup of nmdm device
2002-02-20 20:13:13 +00:00
/*
* Module handling
*/
static int
nmdm_modevent(module_t mod, int type, void *data)
{
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
static eventhandler_tag tag;
struct nm_softc *pt, *tpt;
Cleanup of nmdm device
2002-02-20 20:13:13 +00:00
int error = 0;
switch(type) {
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
case MOD_LOAD:
Add clone_setup() function rather than rely on lazy initialization. Requested by: rwatson
2004-03-11 12:58:55 +00:00
clone_setup(&nmdmclones);
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
tag = EVENTHANDLER_REGISTER(dev_clone, nmdm_clone, 0, 1000);
if (tag == NULL)
return (ENOMEM);
Cleanup of nmdm device
2002-02-20 20:13:13 +00:00
break;
case MOD_SHUTDOWN:
/* FALLTHROUGH */
case MOD_UNLOAD:
Device megapatch 2/6: This commit adds a couple of functions for pseudodrivers to use for implementing cloning in a manner we will be able to lock down (shortly). Basically what happens is that pseudo drivers get a way to ask for "give me the dev_t with this unit number" or alternatively "give me a dev_t with the lowest guaranteed free unit number" (there is unfortunately a lot of non-POLA in the exact numeric value of this number, just live with it for now) Managing the unit number space this way removes the need to use rman(9) to do so in the drivers this greatly simplifies the code in the drivers because even using rman(9) they still needed to manage their dev_t's anyway. I have taken the if_tun, if_tap, snp and nmdm drivers through the mill, partly because they (ab)used makedev(), but mostly because together they represent three different problems for device-cloning: if_tun and snp is the plain case: just give me a device. if_tap has two kinds of devices, with a flag for device type. nmdm has paired devices (ala pty) can you can clone either of them.
2004-02-21 20:29:52 +00:00
EVENTHANDLER_DEREGISTER(dev_clone, tag);
TAILQ_FOREACH_SAFE(pt, &nmdmhead, pt_list, tpt) {
destroy_dev(pt->part1.dev);
TAILQ_REMOVE(&nmdmhead, pt, pt_list);
free(pt, M_NLMDM);
}
clone_cleanup(&nmdmclones);
Cleanup of nmdm device
2002-02-20 20:13:13 +00:00
break;
default:
error = EOPNOTSUPP;
}
return (error);
}
Do it right this time. Give it a better name and place CVSrepo deletion of the previous attempt will be requested: --original message-- Add the 'virtual nulmodem driver' Particularly useful for debuging kernels using vmware. If your name is Bruce evans and you are a WIZ at tty interfaces, then you should probably rip this to shreds and offer lots of suggestions and patches. I've been using this since 4.0-CURRENT and it's never caused problems but I'm sure I got something wrong. This is similar to the pty/cty device driver except that both sides are ttys. Even minor numbers are side A and odd minor numbers are side B. Work needs to be done regarding what happens to the other side when you close a node. to use with vmware, configure vmware to redirect COM2 out to side A of one of these and boot a kernel with teh gdb remote port set to sio1. AFTER dropping into the gdb kernel debugger in your test kernel, fire up gdb with it's remote port pointing at the appropriate side B. To catch all console output, you can boot the vmware kernel with a serial console, (COM1) similarly redirected to a nulmodem, and use 'tip' to observe it. This is practically unaltered since pre 4.0 days except for changes made along the way needed to make it compile, so any suggestions or offers of total rewrites will be listenned to :-)
2001-02-27 16:39:54 +00:00
Cleanup of nmdm device
2002-02-20 20:13:13 +00:00
DEV_MODULE(nmdm, nmdm_modevent, NULL);
Reference in New Issue Copy Permalink