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 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: > | 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, 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: > | - 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
