Re: CVS commit: src/distrib/common/bootimage
On Tue, Mar 17, 2015 at 11:48:51AM +0100, Martin Husemann wrote: > On Tue, Mar 17, 2015 at 11:39:44AM +0100, Joerg Sonnenberger wrote: > > > No, you should not randomly add the expensive ptyfs code to INSTALL > > > kernels > > > you can not test yourself. Everything else above is fine, as long as > > > sysinst > > > is silent on ptyfs failure when the compat ipty nodes are available. > > > > Huh? I fully agree with Christos that we *should* move to ptyfs. As > > such, problems mounting it should *not* be silent. > > What is so unclear about "INSTALL kernels you can not test yourself" ? That's why he said he will keep COMPAT_BSDPTY for now. > And if for some reason the INSTALL kernel in question did NOT choose to > include ptyfs, but the device setup steff properly creates the old style > pty nodes, complaining about anything would be extremely stupid. While the installation will still work, it also allows a report of the problem. So that after some time, the legacy compat *can* be removed. Joerg
Re: CVS commit: src/distrib/common/bootimage
On Mar 17, 1:20pm, mar...@duskware.de (Martin Husemann) wrote: -- Subject: Re: CVS commit: src/distrib/common/bootimage | On Tue, Mar 17, 2015 at 11:53:16AM +, Christos Zoulas wrote: | >Can you please state the criteria that make you say that ptyfs is expensive? | | Ok, I take that back, I completely misremembered: | | As you say, it is like 10kb of code (9.5 on VAX), plus some runtime | data structures. | | And actually on the CD image, I flipped it over to *USE* ptyfs in the | end, as that avoids another tmpfs instance, which was way more expensive. | And the scripts deal with both variants already. Thanks Martin, There are some outliers there where it will make a difference (sun2-FOURMEG etc.). In the end we have to really start thinking about what needs to be done with these ancient configurations. What I am suggesting here, is to make the change on HEAD. If in the next couple of years (assuming we follow our regular release schedule for NetBSD-8), nobody tests and there is a problem with the change so be it. If someone tests and discovers it is broken, then we can fix it. In 2000 it was cool to be able to say that we are running in machines that were 15 years old. It is now 15 years later and those machines are 30 years old, and even if we can run of them, we can't expect anything useful to be done with them other than look at them in astonishment (that they still work and can run -- very slowly). At the other end of the spectrum, there are tons new machines, drivers, subsystems, API's out there that we would like to be able to support. We have only so much manpower, and if we keep bringing forward quirks to support all the old archs we would be wasting resources better spent elsewhere. I am not talking about breaking old ports on purpose; I am just talking about modernizing them. If they survive, good for them. If they die, perhaps it is for the best. Look at what's happening to the VAX port. We all love the port (at least I do), and we have put significant work in carrying it forward (elf/pic/gcc) but still even with our best efforts lately we still don't have a fully working system. Perhaps the best answer is: if you still want a working system for arch look at release . If you are interested in bringing up to speed, more power to you! Go for it, and we'll help you as much as we can. christos
Re: CVS commit: src/distrib/common/bootimage
On Tue, Mar 17, 2015 at 11:53:16AM +, Christos Zoulas wrote: >Can you please state the criteria that make you say that ptyfs is expensive? Ok, I take that back, I completely misremembered: As you say, it is like 10kb of code (9.5 on VAX), plus some runtime data structures. And actually on the CD image, I flipped it over to *USE* ptyfs in the end, as that avoids another tmpfs instance, which was way more expensive. And the scripts deal with both variants already. Martin
Re: CVS commit: src/distrib/common/bootimage
In article <20150317112415.4125617f...@rebar.astron.com>, Christos Zoulas wrote: >On Mar 17, 9:56am, mar...@duskware.de (Martin Husemann) wrote: >-- Subject: Re: CVS commit: src/distrib/common/bootimage > >| No, you should not randomly add the expensive ptyfs code to INSTALL kernels >| you can not test yourself. Everything else above is fine, as long as sysinst >| is silent on ptyfs failure when the compat ipty nodes are available. > >Can you please state the criteria that make you say that ptyfs is expensive? > >The size of the ptyfs kernel module (amd64) >text data bss dec hex filename >10001 328 0 103292859 ptyfs.kmod > >The sizes of the install kernels between releases (amd64 again): > >textdata bssdec hex filename >101855795693216 781728 16660523 fe382b netbsd-5.2.3-INSTALL >112344095724168 623712 1758228910c48d1 netbsd-6.1.5-INSTALL > >We can do the same with whichever kernel you want. For example sun2: text data bssdec hexfilename 1073288 26968 201900 1302156 13de8c netbsd-5.2.3-INSTALL 1195647 37148 86296 1319091 1420b3 netbsd-6.1.5-INSTALL christos
Re: CVS commit: src/distrib/common/bootimage
On Mar 17, 9:56am, mar...@duskware.de (Martin Husemann) wrote: -- Subject: Re: CVS commit: src/distrib/common/bootimage | No, you should not randomly add the expensive ptyfs code to INSTALL kernels | you can not test yourself. Everything else above is fine, as long as sysinst | is silent on ptyfs failure when the compat ipty nodes are available. Can you please state the criteria that make you say that ptyfs is expensive? The size of the ptyfs kernel module (amd64) text data bss dec hex filename 10001 328 0 103292859 ptyfs.kmod The sizes of the install kernels between releases (amd64 again): textdata bssdec hex filename 101855795693216 781728 16660523 fe382b netbsd-5.2.3-INSTALL 112344095724168 623712 1758228910c48d1 netbsd-6.1.5-INSTALL We can do the same with whichever kernel you want. christos
Re: CVS commit: src/distrib/common/bootimage
On Tue, Mar 17, 2015 at 11:39:44AM +0100, Joerg Sonnenberger wrote: > > No, you should not randomly add the expensive ptyfs code to INSTALL kernels > > you can not test yourself. Everything else above is fine, as long as sysinst > > is silent on ptyfs failure when the compat ipty nodes are available. > > Huh? I fully agree with Christos that we *should* move to ptyfs. As > such, problems mounting it should *not* be silent. What is so unclear about "INSTALL kernels you can not test yourself" ? And if for some reason the INSTALL kernel in question did NOT choose to include ptyfs, but the device setup steff properly creates the old style pty nodes, complaining about anything would be extremely stupid. Martin
Re: CVS commit: src/distrib/common/bootimage
On Tue, Mar 17, 2015 at 09:56:18AM +0100, Martin Husemann wrote: > On Mon, Mar 16, 2015 at 02:02:11PM -0400, Christos Zoulas wrote: > > My vote is to keep compat code, add ptyfs to all install kernels, and > > try mounting ptyfs from sysinst before openpty. > > No, you should not randomly add the expensive ptyfs code to INSTALL kernels > you can not test yourself. Everything else above is fine, as long as sysinst > is silent on ptyfs failure when the compat ipty nodes are available. Huh? I fully agree with Christos that we *should* move to ptyfs. As such, problems mounting it should *not* be silent. Joerg
Re: CVS commit: src/distrib/common/bootimage
On Mon, Mar 16, 2015 at 02:02:11PM -0400, Christos Zoulas wrote: > My vote is to keep compat code, add ptyfs to all install kernels, and > try mounting ptyfs from sysinst before openpty. No, you should not randomly add the expensive ptyfs code to INSTALL kernels you can not test yourself. Everything else above is fine, as long as sysinst is silent on ptyfs failure when the compat ipty nodes are available. Martin
Re: CVS commit: src/distrib/common/bootimage
On Mar 17, 1:58am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/distrib/common/bootimage | > | IMO we should rather focus on marketing than consistency for developers... | > | > Can you please expand? I don't understand how marketing helps existing | > developers. | | No user, no feedback? If there are no users, then there is no point in carrying stuff forward. | For example, most (all?) other ports still have opty. | You also have to check MAKEDEVTARGETS= in Makefiles under src/distrib. | That was the reason why we failed before. Ok. | Then I asked not only the goal but also actual procedure how to | avoid possible fallout. Everything can be done, but we are | far from the perfect. | | My vote is to keep compat code for now and just try mount(2) ptyfs | when openpty(3) failed for better migration, as I wrote in the PR. | | Anyway, I think our discussion is over and we need votes from others. My vote is to keep compat code, add ptyfs to all install kernels, and try mounting ptyfs from sysinst before openpty. christos
Re: CVS commit: src/distrib/common/bootimage
christos@ wrote: > On Mar 16, 3:59am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: > -- Subject: Re: CVS commit: src/distrib/common/bootimage > > | > You are right, but it makes it cheaper for us to maintain things > | > in the long run and improves consistency and robustness. > | > | IMO we should rather focus on marketing than consistency for developers... > > Can you please expand? I don't understand how marketing helps existing > developers. No user, no feedback? > | > I don't think that we are going to be getting new users from the > | > sun2 or sun3 ports... And even if we do, these are the "expert" > | > users who will help us debug the problem. > | > | You should re-read PRs. There were much more ports that failed on 6.0. > > I just see the following having ipty still. Either many more are broken > and are not used by anyone, or they work: > > etc.hp300/MAKEDEV.conf: makedev ipty > etc.i386/MAKEDEV.conf: makedev ipty > etc.landisk/MAKEDEV.conf: makedev ipty > etc.luna68k/MAKEDEV.conf: makedev ipty ttya > etc.sbmips/MAKEDEV.conf:makedev ipty > etc.sgimips/MAKEDEV.conf: makedev ipty > etc.vax/MAKEDEV.conf: makedev std bpf md0 ipty mt0 st0 rd0 rd1 dz0 dl0 dhu0 For example, most (all?) other ports still have opty. You also have to check MAKEDEVTARGETS= in Makefiles under src/distrib. That was the reason why we failed before. > | In pre-6.0 days, we tried to fix all installation MAKEDEV targets, > | but actually it failed. "It's easier said than done." > > I agree, but it can be done. Then I asked not only the goal but also actual procedure how to avoid possible fallout. Everything can be done, but we are far from the perfect. My vote is to keep compat code for now and just try mount(2) ptyfs when openpty(3) failed for better migration, as I wrote in the PR. Anyway, I think our discussion is over and we need votes from others. --- Izumi Tsutsui
Re: CVS commit: src/distrib/common/bootimage
On Mar 16, 3:59am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/distrib/common/bootimage | > You are right, but it makes it cheaper for us to maintain things | > in the long run and improves consistency and robustness. | | IMO we should rather focus on marketing than consistency for developers... Can you please expand? I don't understand how marketing helps existing developers. | > I don't think that we are going to be getting new users from the | > sun2 or sun3 ports... And even if we do, these are the "expert" | > users who will help us debug the problem. | | You should re-read PRs. There were much more ports that failed on 6.0. I just see the following having ipty still. Either many more are broken and are not used by anyone, or they work: etc.hp300/MAKEDEV.conf: makedev ipty etc.i386/MAKEDEV.conf: makedev ipty etc.landisk/MAKEDEV.conf: makedev ipty etc.luna68k/MAKEDEV.conf: makedev ipty ttya etc.sbmips/MAKEDEV.conf:makedev ipty etc.sgimips/MAKEDEV.conf: makedev ipty etc.vax/MAKEDEV.conf: makedev std bpf md0 ipty mt0 st0 rd0 rd1 dz0 dl0 dhu0 | If you changed PTYFS mandatory for sysinst and | you forget to add file-system PTYFS to some installation | kernel config files, the similar failures could happen. Yes, there is a bunch of config lines that are mandatory per port. Same if you don't put COMPAT_BSDPTY. | In pre-6.0 days, we tried to fix all installation MAKEDEV targets, | but actually it failed. "It's easier said than done." I agree, but it can be done. christos
Re: CVS commit: src/distrib/common/bootimage
christos@ wrote: > On Mar 15, 4:47pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: > -- Subject: Re: CVS commit: src/distrib/common/bootimage > > | Well, "old code eliminations" gives nothing to users. > > You are right, but it makes it cheaper for us to maintain things > in the long run and improves consistency and robustness. IMO we should rather focus on marketing than consistency for developers... > | I would rather like to see a proper migration plan > | how to eliminate it without regressions, especially on install. > | (If installation fails we won't get possible new users) > > I don't think that we are going to be getting new users from the > sun2 or sun3 ports... And even if we do, these are the "expert" > users who will help us debug the problem. You should re-read PRs. There were much more ports that failed on 6.0. If you changed PTYFS mandatory for sysinst and you forget to add file-system PTYFS to some installation kernel config files, the similar failures could happen. > | In pre-6.0 days compat pty nodes were removed > | from MAKEDEV all target without annoucement, then > | a certain number of Tier-II users failed to install > | on their favorite machines with unclear "openpty() failed" > | messages during installation. > | > | One possible kludge is adding "file-system PTYFS" into conf/std, > | but I don't think we can make consensus with it. > > Or go and add it to all the install kernels (as I mentioned before). > There is no precedence for adding filesystems to conf/std. In pre-6.0 days, we tried to fix all installation MAKEDEV targets, but actually it failed. "It's easier said than done." --- Izumi Tsutsui
Re: CVS commit: src/distrib/common/bootimage
On Mar 15, 4:47pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/distrib/common/bootimage | Well, "old code eliminations" gives nothing to users. You are right, but it makes it cheaper for us to maintain things in the long run and improves consistency and robustness. | I would rather like to see a proper migration plan | how to eliminate it without regressions, especially on install. | (If installation fails we won't get possible new users) I don't think that we are going to be getting new users from the sun2 or sun3 ports... And even if we do, these are the "expert" users who will help us debug the problem. | In pre-6.0 days compat pty nodes were removed | from MAKEDEV all target without annoucement, then | a certain number of Tier-II users failed to install | on their favorite machines with unclear "openpty() failed" | messages during installation. | | One possible kludge is adding "file-system PTYFS" into conf/std, | but I don't think we can make consensus with it. Or go and add it to all the install kernels (as I mentioned before). There is no precedence for adding filesystems to conf/std. christos
Re: CVS commit: src/distrib/common/bootimage
christos@ wrote: > On Mar 14, 11:36pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: > -- Subject: Re: CVS commit: src/distrib/common/bootimage > > | Silent possible installation failure we saw in 6.0 as mentioned in PRs > | was bad enough for users. > | > | What is "good" on the other hand? Design? Secure during installation? > > I think consistency and old code elimination counts... I think we can > test sun2 and sun3 with TME. Well, "old code eliminations" gives nothing to users. I would rather like to see a proper migration plan how to eliminate it without regressions, especially on install. (If installation fails we won't get possible new users) In pre-6.0 days compat pty nodes were removed from MAKEDEV all target without annoucement, then a certain number of Tier-II users failed to install on their favorite machines with unclear "openpty() failed" messages during installation. One possible kludge is adding "file-system PTYFS" into conf/std, but I don't think we can make consensus with it. --- Izumi Tsutsui
Re: CVS commit: src/distrib/common/bootimage
We have #ifdef SMALL on various userland tools - iff we keep COMPAT_BSDTTY purely for similar reasons it should probably be renamed to make it clear its intended purpose. For smaller systems its not just the overall image size, its also the runtime memory used (I remember switching from mount_kernfs to dmesg being a net space win at runtime). Packing vax a good example of low memory system (and one easy to test on x86 hardware in simh) it would be interesting to see the difference in both image size and available memory once booted between COMPAT_BSDPTY and PTYFS+mount_ptyfs, The runtime memory usage is probably going to be the limiting factor long term - for for example a kernel+ramdisk floppy could be switched to a kernel floppy and a root filesystem floppy, which could help considerably on low ram systems at the cost of locking up a floppy drive during install (and obviously making everything much slower :) Maybe the answer is to so as Sun did with their Sun/386i and implement pageable kernel text :-p On 14 March 2015 at 13:49, Christos Zoulas wrote: > On Mar 14, 11:02am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: > -- Subject: Re: CVS commit: src/distrib/common/bootimage > > | It is a bit annoying to shrink ever growing kernels... > | sun2 and sun3 have size restriction due to bootloader, for example. > | (Of course I know these poor ports should retire in near future) > > I'll test and see the size difference on those two. > > | The "3. add file-system PTYFS to all the kernels" > | seems a bit hard as we saw on PR/46812 and PR/47123 > | (we had to add ipty or opty into all MD MAKEDEV). > | > | I can see your reasonable goal, but we need to consider pros and cons. > | That's all. > > Yes, that's why I am asking... I don't know how bad it can get. > > christos
Re: CVS commit: src/distrib/common/bootimage
On Fri, Mar 13, 2015 at 03:36:38PM -0400, Christos Zoulas wrote: > I was trying to avoid carrying over the old pty code around forever, > and having all the ports doing it in a unified way. I guess it does > not matter too much for the installer, but it does add complexity... > I think if you remove COMPAT_BSDTTY and just have PTYFS the code is > only a few K larger. Removing the COMPAT_BSDTTY in openpty saves 600 Bytes on ARM too, likely there are other places that can benefit as well... Joerg
Re: CVS commit: src/distrib/common/bootimage
On Mar 14, 11:36pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/distrib/common/bootimage | Silent possible installation failure we saw in 6.0 as mentioned in PRs | was bad enough for users. | | What is "good" on the other hand? Design? Secure during installation? I think consistency and old code elimination counts... I think we can test sun2 and sun3 with TME. christos
Re: CVS commit: src/distrib/common/bootimage
christos@ wrote: > | The "3. add file-system PTYFS to all the kernels" > | seems a bit hard as we saw on PR/46812 and PR/47123 > | (we had to add ipty or opty into all MD MAKEDEV). > | > | I can see your reasonable goal, but we need to consider pros and cons. > | That's all. > > Yes, that's why I am asking... I don't know how bad it can get. Silent possible installation failure we saw in 6.0 as mentioned in PRs was bad enough for users. What is "good" on the other hand? Design? Secure during installation? --- Izumi Tsutsui
Re: CVS commit: src/distrib/common/bootimage
On Mar 14, 11:02am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/distrib/common/bootimage | It is a bit annoying to shrink ever growing kernels... | sun2 and sun3 have size restriction due to bootloader, for example. | (Of course I know these poor ports should retire in near future) I'll test and see the size difference on those two. | The "3. add file-system PTYFS to all the kernels" | seems a bit hard as we saw on PR/46812 and PR/47123 | (we had to add ipty or opty into all MD MAKEDEV). | | I can see your reasonable goal, but we need to consider pros and cons. | That's all. Yes, that's why I am asking... I don't know how bad it can get. christos
Re: CVS commit: src/distrib/common/bootimage
christos@ wrote: > | - there are so many ramdisk lists > | - some ports still have 1440KB restriction due to installation floppy > > These are detected during build... It is a bit annoying to shrink ever growing kernels... sun2 and sun3 have size restriction due to bootloader, for example. (Of course I know these poor ports should retire in near future) > | - few people will bother to maintain such lists just for installer > | > | The point of my PR is "unfortunately we always lack man power," > | as no one have take a look at the problem even after 6.0. > | > | If you can sweep all image list files and kernel config files > | without regressions, it's fine for me. > > There is no way to test many of those things. What I was suggesting was: > > 1. kill ipty from all the MAKEDEV lists > 2. add mount(PTYFS) to sysinst. > 3. add file-system PTYFS to all the kernels. > > If the floppies fit, then it has a good chance to work... What can go wrong? > (famous last words) The "3. add file-system PTYFS to all the kernels" seems a bit hard as we saw on PR/46812 and PR/47123 (we had to add ipty or opty into all MD MAKEDEV). I can see your reasonable goal, but we need to consider pros and cons. That's all. --- Izumi Tsutsui
Re: CVS commit: src/distrib/common/bootimage
On Mar 14, 4:50am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/distrib/common/bootimage | christos@ wrote: | | > | 3. fallback to mount ptyfs via direct mount(2) in sysinst only when | > |openpty(3) fails, so that poor Tier II ports still use old way | > |without file-system PTYFS and we don't have to touch a number of | > |crunch lists to add mount_ptyfs(8). That's what my PR/47774 intended. | > | > I was trying to avoid carrying over the old pty code around forever, | > and having all the ports doing it in a unified way. | | It sounds a bit paranoiac (i.e. best or nothing strategy) for me. No, I just think that all ports should run with ptyfs during normal use, so why not during installation. | > I guess it does | > not matter too much for the installer, but it does add complexity... | > I think if you remove COMPAT_BSDTTY and just have PTYFS the code is | > only a few K larger. | | - there are so many ramdisk lists | - some ports still have 1440KB restriction due to installation floppy These are detected during build... | - few people will bother to maintain such lists just for installer | | The point of my PR is "unfortunately we always lack man power," | as no one have take a look at the problem even after 6.0. | | If you can sweep all image list files and kernel config files | without regressions, it's fine for me. There is no way to test many of those things. What I was suggesting was: 1. kill ipty from all the MAKEDEV lists 2. add mount(PTYFS) to sysinst. 3. add file-system PTYFS to all the kernels. If the floppies fit, then it has a good chance to work... What can go wrong? (famous last words) christos
Re: CVS commit: src/distrib/common/bootimage
christos@ wrote: > | 3. fallback to mount ptyfs via direct mount(2) in sysinst only when > |openpty(3) fails, so that poor Tier II ports still use old way > |without file-system PTYFS and we don't have to touch a number of > |crunch lists to add mount_ptyfs(8). That's what my PR/47774 intended. > > I was trying to avoid carrying over the old pty code around forever, > and having all the ports doing it in a unified way. It sounds a bit paranoiac (i.e. best or nothing strategy) for me. > I guess it does > not matter too much for the installer, but it does add complexity... > I think if you remove COMPAT_BSDTTY and just have PTYFS the code is > only a few K larger. - there are so many ramdisk lists - some ports still have 1440KB restriction due to installation floppy - few people will bother to maintain such lists just for installer The point of my PR is "unfortunately we always lack man power," as no one have take a look at the problem even after 6.0. If you can sweep all image list files and kernel config files without regressions, it's fine for me. --- Izumi Tsutsui
Re: CVS commit: src/distrib/common/bootimage
On Mar 14, 2:28am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/distrib/common/bootimage | christos@ wrote: | | > On Mar 13, 3:30am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: | > -- Subject: Re: CVS commit: src/distrib/common/bootimage | > | > | christos@ wrote: | > | | > | > Why are they broken? The INSTALL kernel has ptyfs now? This is the | > | > wrong fix in the long run... | > | | > | BTW no one takes PR install/47774 (and the following thread) even after 6.0. | > | http://mail-index.netbsd.org/source-changes-d/2012/09/thread1.html#005236 | > | > Well, do we have a consensus on how do we want to do this? | | No particular comment implies no consensus? | | > 1. make mount_ptyfs mandatory and run it via mi code (where?) | > 2. mount ptyfs in sysinst using c code, and remove all the MD hacks. | | 3. fallback to mount ptyfs via direct mount(2) in sysinst only when |openpty(3) fails, so that poor Tier II ports still use old way |without file-system PTYFS and we don't have to touch a number of |crunch lists to add mount_ptyfs(8). That's what my PR/47774 intended. I was trying to avoid carrying over the old pty code around forever, and having all the ports doing it in a unified way. I guess it does not matter too much for the installer, but it does add complexity... I think if you remove COMPAT_BSDTTY and just have PTYFS the code is only a few K larger. christos
Re: CVS commit: src/distrib/common/bootimage
christos@ wrote: > On Mar 13, 3:30am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: > -- Subject: Re: CVS commit: src/distrib/common/bootimage > > | christos@ wrote: > | > | > Why are they broken? The INSTALL kernel has ptyfs now? This is the > | > wrong fix in the long run... > | > | BTW no one takes PR install/47774 (and the following thread) even after 6.0. > | http://mail-index.netbsd.org/source-changes-d/2012/09/thread1.html#005236 > > Well, do we have a consensus on how do we want to do this? No particular comment implies no consensus? > 1. make mount_ptyfs mandatory and run it via mi code (where?) > 2. mount ptyfs in sysinst using c code, and remove all the MD hacks. 3. fallback to mount ptyfs via direct mount(2) in sysinst only when openpty(3) fails, so that poor Tier II ports still use old way without file-system PTYFS and we don't have to touch a number of crunch lists to add mount_ptyfs(8). That's what my PR/47774 intended. --- Izumi Tsutsui
Re: CVS commit: src/distrib/common/bootimage
On Thu, Mar 12, 2015 at 03:09:55PM -0400, Christos Zoulas wrote: > 1. make mount_ptyfs mandatory and run it via mi code (where?) > 2. mount ptyfs in sysinst using c code, and remove all the MD hacks. As long as the end result still works on kernels w/o ptyfs, I'm fine. I think I tested on tiny memory VAXes and the kernel with COMPAT_BSDPTY and without PTYFS was significantly smaller. Martin
Re: CVS commit: src/distrib/common/bootimage
On Mar 13, 3:30am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/distrib/common/bootimage | christos@ wrote: | | > Why are they broken? The INSTALL kernel has ptyfs now? This is the | > wrong fix in the long run... | | BTW no one takes PR install/47774 (and the following thread) even after 6.0. | http://mail-index.netbsd.org/source-changes-d/2012/09/thread1.html#005236 Well, do we have a consensus on how do we want to do this? 1. make mount_ptyfs mandatory and run it via mi code (where?) 2. mount ptyfs in sysinst using c code, and remove all the MD hacks. christos
