Re: RFC: Remove pty(4)
On 11/28/14, 2: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 ? [...] 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. [...] 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. [...] Thank you kib, I feel the same about leaving the pty system as it is. the pty ABI is so well known and so ubiquitous that I think changing it in any major way is asking for trouble. Also whatever you do, jails running 4.x (or older) software MUST continue to run, and be able to have ptys behave as they expect. -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
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). Thank you kib, I feel the same about leaving the pty system as it is. -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
I've recently created a port for linux-sublime and some of the packages users might add to sublime require loading pty. I haven't read the full thread so I'm not sure what would actually be removed but If there no reason for it I don't see why waste the time on such a task. is there for example any security concern about using the pty driver? thanks On 27 November 2014 12:41:56 WET, Poul-Henning Kamp wrote: > >In message <20141127095229.go17...@kib.kiev.ua>, Konstantin Belousov >writes: > >>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 ? > >I must have missed this detail back in august. > >I checked my archive of incoming email and I couldn't find any >reason or argument for removing dev_clone mechanism, and I would >very much object to its removal, unless a very compelling reason >exists ? > >I'll admit that the name is slightly misleading, it is really >a "dev_ondemand" facility which can also be used for cloning, >and because all the initial uses were cloning it got that name. > >(I have no soft feelings for the pty driver) > >-- >Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >p...@freebsd.org | TCP/IP since RFC 956 >FreeBSD committer | BSD since 4.3-tahoe >Never attribute to malice what can adequately be explained by >incompetence. >___ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to >"freebsd-current-unsubscr...@freebsd.org" -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
In message <20141127095229.go17...@kib.kiev.ua>, Konstantin Belousov writes: >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 ? I must have missed this detail back in august. I checked my archive of incoming email and I couldn't find any reason or argument for removing dev_clone mechanism, and I would very much object to its removal, unless a very compelling reason exists ? I'll admit that the name is slightly misleading, it is really a "dev_ondemand" facility which can also be used for cloning, and because all the initial uses were cloning it got that name. (I have no soft feelings for the pty driver) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
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). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
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. >> 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. >> >> 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. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
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. > 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. > > 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. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
Sam Fourman Jr. On Aug 20, 2014 1:00 PM, "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 <= 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. > > 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. > > -- > Davide > I am all for the advancement of FreeBSD, but I for one maintain appliance products based on 7.x, most of the time I vote for out with the old in with the new... But are we certain all options for keeping compat have been explored? Just my 2c Sam Fourman Jr. > "There are no solved problems; there are only problems that are more > or less solved" -- Henri Poincare > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
On Wed, Aug 20, 2014 at 11:00:14AM -0700, 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 <= 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. FreeBSD EOL, but still working. # uname -a FreeBSD XXX 5.4-STABLE FreeBSD 5.4-STABLE #3: Fri Mar 29 13:52:44 MSK 2013 slw@:/usr/obj/usr/src/sys/RADIUS i386 And may be exist software for this version, don't exist for modern OS. > 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. Waht about porting software, relaying on /dev/ptyXX and /dev/ttyXX? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
On 8/20/2014 1:13 PM, Julian Elischer wrote: > 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 <= 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. >> >> 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. > I agree with Alfred. > breaking old jails is a no no. > many people still use them. Me included. > I sometimes run jails back to 1.1, > not everything works, but enough does to build 1.1 binaries for certain > devices. +1 to keeping compat. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: RFC: Remove pty(4)
> On Aug 20, 2014, at 11:05, Alfred Perlstein wrote: > >> 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 <= 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. >> >> 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. > I don't think that we want to break userland apps pre-7.x. Do you mean just > 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 > maintaining the old interface? Doing this would also break login shells, xterms, etc, right? Some companies I worked for built their appliance products on newer OSes, and they were 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 new interface. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
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 <= 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. 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. I agree with Alfred. breaking old jails is a no no. many people still use them. Me included. I sometimes run jails back to 1.1, not everything works, but enough does to build 1.1 binaries for certain devices. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
On 08/20/14 20:00, 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 <= 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. 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. Hi, There is support for creating character device aliases, regarding paired devices. BTW: Can an application using libcuse fix this issue in userspace? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: Remove pty(4)
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 <= 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. 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. I don't think that we want to break userland apps pre-7.x. Do you mean just 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 maintaining the old interface? -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RFC: Remove pty(4)
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 <= 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. 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. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
