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
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
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 th
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
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
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 availabl
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
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. Everythi
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
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 robust
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 fo
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
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 consi
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 &qu
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/
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 remov
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? Sec
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
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
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 c
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 o
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
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:
> 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
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 mem
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 (a
26 matches
Mail list logo
