From owner-freebsd-current@FreeBSD.ORG Thu Nov 27 20:51:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E09E734 for ; Thu, 27 Nov 2014 20:51:17 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C114CBC9 for ; Thu, 27 Nov 2014 20:51:16 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id hz20so4593146lab.20 for ; Thu, 27 Nov 2014 12:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6/Phl9xckV3r34PuTnOmU7+X2fByPOlEIOiJ5Q4TbtY=; b=FI6Rj7+dFUAol4lowfEUSgWVFx3p/CSixrNniqCmA6NzqtynfC3lW6724G4W61ORpR knB7SqzRQq9szoB/XwAr7OxQCFv/Dsal2NZKuMkGuCe2nv9uphckISNRtmYicAZ49ocu raRCNTxdmLgaeHE9iESJjFelNo5L2aRryWethZoqjYCV61dcxw8gVEypmqEi9qaGfXIG pRt8chO6qEEEtIqN1owHvzCmNYaWoEIjG2kFT5oqidk44G6PEyua1gxZESND0DRx7kTW LEoNa03AUQ7ru6t/47EKLq3qwg0rF6cl2CLZ2YueKTimbX5Y05yKAtEqJh1xrfB4PyJD ocrA== MIME-Version: 1.0 X-Received: by 10.112.73.102 with SMTP id k6mr27830366lbv.75.1417121474904; Thu, 27 Nov 2014 12:51:14 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.25.155.4 with HTTP; Thu, 27 Nov 2014 12:51:14 -0800 (PST) In-Reply-To: <58F613B8-1F1E-4A38-8955-F35EB31A703A@mu.org> References: <1471750.VzNR6ldJSe@ralph.baldwin.cx> <20141127095229.GO17068@kib.kiev.ua> <58F613B8-1F1E-4A38-8955-F35EB31A703A@mu.org> Date: Thu, 27 Nov 2014 12:51:14 -0800 X-Google-Sender-Auth: CeJPi4hDHwLAWKQSDEW5KzkDg8U Message-ID: Subject: Re: RFC: Remove pty(4) From: Davide Italiano To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , Ed Schouten , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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: Thu, 27 Nov 2014 20:51:17 -0000 On Thu, Nov 27, 2014 at 10:37 AM, Alfred Perlstein wrote: > > On Nov 27, 2014, at 1:52 AM, Konstantin Belousov wrote: > >> On Wed, Nov 26, 2014 at 04:41:27PM -0800, Davide Italiano wrote: >>> On Mon, Aug 25, 2014 at 12:37 PM, John Baldwin wrote: >>>> On Wednesday, August 20, 2014 11:00:14 AM Davide Italiano wrote: >>>>> One of my personal goals for 11 is to get rid of cloning mechanism >>>>> entirely, and pty(4) is one of the few in-kernel drivers still relying >>>>> on such mechanism. >> Why this is good thing to do ? >> >>>>> It's not possible, at least to my understanding, converting pty(4) to >>>>> cdevpriv(9) as happened with other drivers. This is mainly because we >>>>> always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and >>>>> userspace loops over ptyXX and after it successfully opens it tries to >>>>> open the other one with the same suffix. So, having a single device is >>>>> not really enough. >>>>> My option, instead, is that of removing pty(4), which is nothing more >>>>> than a compatibility driver, and move pmtx(4) code somewhere else. >>>>> The main drawback of the removal of this is that it makes impossible >>>>> to run FreeBSD <= 7 jails and SSH into them. I personally don't >>>>> consider this a huge issue, in light of the fact that FreeBSD-7 has >>>>> been EOL for a long time, but I would like to hear other people >>>>> comments. >> You don't, but other people care about ABI. >> >> Besides older jails which you do not care about, there is significant >> set of programs which were coded to use Berkley' pty directly. Even >> high-profile applications like Emacs automatically selected pty(4) >> up to its previous version on FreeBSD. >> >>>>> >>>>> The code review for the proposed change can be found here: >>>>> https://reviews.freebsd.org/D659 >>>>> >>>>> If I won't get any objection I'll commit this in one week time, i.e. >>>>> August 27th. >>>> >>>> Why not just statically create the pairs in /dev? Use some loader tunable >>>> (kern.ptymax) to set a count on the number of pre-created device pairs to >>>> create and then just explicitly create them in the mod_event handler? It >>>> could default to 100 or so. >>>> >>> >>> Done, thank you for the suggestion, John. >>> >>> root@maxwell:/home/davide # kldload pty >>> root@maxwell/home/davide # sysctl -a |grep pty >>> kern.tty_pty_warningcnt: 1 >>> kern.npty: 32 >>> debug.softdep.emptyjblocks: 0 >>> >>> root@maxwell:/home/davide # ls /dev/pty* >>> /dev/ptyl0 /dev/ptyl2 /dev/ptyl4 /dev/ptyl6 /dev/ptyl8 /dev/ptyla >>> /dev/ptylc /dev/ptyle /dev/ptylg /dev/ptyli /dev/ptylk /dev/ptylm >>> /dev/ptylo /dev/ptylq /dev/ptyls /dev/ptylu >>> /dev/ptyl1 /dev/ptyl3 /dev/ptyl5 /dev/ptyl7 /dev/ptyl9 /dev/ptylb >>> /dev/ptyld /dev/ptylf /dev/ptylh /dev/ptylj /dev/ptyll /dev/ptyln >>> /dev/ptylp /dev/ptylr /dev/ptylt /dev/ptylv >>> >>> https://reviews.freebsd.org/D1238 for review. >>> I hope anybody that raised concerns about the previous patch can try >>> this new one. >> >> I do not see why dev_clone event makes your so unhappy. I object against >> removal of it (and this is what you are aiming at, it seems). It provides >> useful functionality, which is not substituted by anything cdevpriv(9) >> can provide. >> >> My only hope is that you are confusing dev_clone event and a library of >> clone_create(9)/clone_cleanup(9)/dev_stdclone(9) functions. The former >> is needed and cannot be replaced by cdevpriv(9). >> >> The later is clumsy and never was used properly. My opinion is that it >> is impossible to use properly. There are five uses of that in tree left, >> and it seems that removing them worth cleaning of buggy by design and >> undocumented KPI. >> >> Really big and complicated target is the hand-written timeout-based (?!) >> custom cloning code in snd(4). I believe it _can_ be converted to >> cdevpriv(9). > All right, I dropped the review and reverted my branch. Thanks for the comment(s). -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare