From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 19:08:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F89D1065672 for ; Tue, 17 Feb 2009 19:08:00 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by mx1.freebsd.org (Postfix) with ESMTP id D21CE8FC22 for ; Tue, 17 Feb 2009 19:07:59 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk24 with SMTP id 24so5670534gxk.19 for ; Tue, 17 Feb 2009 11:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ppb0j+d4zxXHNCJfvkufBdkbzrZeV0KS19JOxiZCg78=; b=KIgOPzNs6YgtxQOZgh8JDH62Bxuq4U25k7wcROldhiJhHSiSkDVTfArzxr/mQheV9z SHoCTegMqqdCHznnGZdjcHgOjtyIv6K6uFdjxhRnn70Foiwj2n3utW4Kq18kH70VcK5X oWW4vDuCxoCafE3+h0ID9vFm7MiGjQ/N3L3Cg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dOkL3eizkSdGPRb2gmbEqgdy2xLUfNbouh+y+PM3itxVpIVAxYA4LYTNNrRHp9EqOy u4a2Aa1El1dIbTbylOVgw2PdCTLVH62E1cW1ZpKWCszGY6ztt5vAbA/pcCeOKbYOV8y1 MDeAbHge1wOdwOaWHMtdWPwkV+vej0sGK6uH4= MIME-Version: 1.0 Received: by 10.231.20.1 with SMTP id d1mr1215004ibb.19.1234897678871; Tue, 17 Feb 2009 11:07:58 -0800 (PST) In-Reply-To: <20090217182128.GH79178@hoeg.nl> References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <20090217175512.GG79178@hoeg.nl> <20090217182128.GH79178@hoeg.nl> Date: Tue, 17 Feb 2009 11:07:58 -0800 Message-ID: From: Maksim Yevmenkin To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Butler , current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:08:00 -0000 On Tue, Feb 17, 2009 at 10:21 AM, Ed Schouten wrote: > Hi Maksim, > > * Maksim Yevmenkin wrote: >> On Tue, Feb 17, 2009 at 9:55 AM, Ed Schouten wrote: >> > * Maksim Yevmenkin wrote: >> >> so, for now, i think we should keep rfcomm_sppd(1) as it is. if this >> >> is not an option (with new tty subsystem) then we should convert it to >> >> use nmdm(4) or something similar. >> > >> > Well, the problem with the current approach is that if you remove >> > "device pty" from your kernel config, it won't work. With MPSAFE TTY we >> > switched to Unix98-style pseudo-terminals, so the preferred mechanism is >> > to call posix_openpt() (or open /dev/ptmx) and use ptsname() to >> > determine which character device to use. >> >> is there a way allocate tty with a given name under "new world order"? > > No, there isn't. I have been thinking about this. Allowing > pseudo-terminals to be allocated with a certain name would allow us to > do things like implementing device drivers as a daemon in userspace. ok >> > I won't change anything now, but will keep my patch at the before >> > mentioned URL. >> >> like i said, the only problem i have here is that any rfcomm_sppd >> callers will have to do extra work to figure which tty was allocated. >> that is the biggest difference from user's point of view. > > Well, we already have existing tools that use such an approach as well, > like mdmconfig. They print a name of the md device to stdout. I'm not > saying I'm 100% happy with this approach, but it's more correct than > just reserving a certain pseudo-terminal device name. do you mean mdconfig(8) and its ability to print auto-allocated /dev/md device unit? if so, it can also allocate specific /dev/md unit, so it really has both options. your patch simply eliminates one of the option and forces users to always use auto-allocation. i'm not saying its bad, i'm just saying its different from what it used to be. that is all. anyway, i guess conversion to nmdm(4) is in order then. at least this way users will have to change /dev/tty to /dev/nmdm which is possibly less pain than other alternatives. while we are at it, we also could implement your approach, i.e. auto-allocate and print /dev/nmdm node if requested. thanks, max