Date: Wed, 20 Aug 2014 11:16:26 -0700 From: Garrett Cooper <yaneurabeya@gmail.com> To: Alfred Perlstein <bright@mu.org> Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: RFC: Remove pty(4) Message-ID: <9D23D164-E7D1-40EB-91AE-FD5DA1F2EB65@gmail.com> In-Reply-To: <53F4E37A.6020702@mu.org> References: <CACYV=-E1BA3rHP5s%2BCs-X-J5CNAaSNxDgqPkgnJu3uUXCyaUGA@mail.gmail.com> <53F4E37A.6020702@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Aug 20, 2014, at 11:05, Alfred Perlstein <bright@mu.org> wrote: >=20 >> On 8/20/14 11:00 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. >> 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 <=3D 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. >>=20 >> The code review for the proposed change can be found here: >> https://reviews.freebsd.org/D659 >>=20 >> If I won't get any objection I'll commit this in one week time, i.e. >> August 27th. > I don't think that we want to break userland apps pre-7.x. Do you mean ju= st jails are broken? Or is all pre-7.x compat? I believe either is dicey. = What is the reason for getting rid of cloning? What is the difficulty in ma= intaining the old interface? Doing this would also break login shells, xterms, etc, right? Some compa= nies I worked for built their appliance products on newer OSes, and they wer= e based off of 6 and 7. This seems like something that deserves being tossed= into the compat layer if it's something that can be converted over to the n= ew interface. Thanks! -Garrett=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9D23D164-E7D1-40EB-91AE-FD5DA1F2EB65>