On Mon, Aug 25, 2014 at 12:37 PM, John Baldwin <j...@freebsd.org> 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
>> The code review for the proposed change can be found here:
>> 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
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.
"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"