[9fans] other kernel bug

[9fans] other kernel bug

[Yoann Padioleau]

Hi,

I think I've found another one :)

in confinit() we do:

    kmem -= conf.upages*sizeof(Page)
            + conf.nproc*sizeof(Proc)
            + conf.nimage*sizeof(KImage)
            + conf.nswap
            + conf.nswppo*sizeof(Page); // <- BUG

but in swapinit we actually do
    iolist = xalloc(conf.nswppo*sizeof(Page*));

so in confinit() it should be conf.nswppo*sizeof(Page*)

Re: [9fans] other kernel bug

[cinap_lenrek]

correct.

--
cinap

Re: [9fans] other kernel bug

[Bruce Ellis]

[-- Attachment #1: Type: text/plain, Size: 144 bytes --]

Could this solve the 'why is swap so crappy?'
On 05/06/2014 11:58 AM, <cinap_lenrek@felloff.net> wrote:

> correct.
>
> --
> cinap
>
>

[-- Attachment #2: Type: text/html, Size: 400 bytes --]

Re: [9fans] other kernel bug

[cinap_lenrek]

no. it just makes the kernels malloc arena limit a bit smaller than
it should be.

--
cinap

Re: [9fans] other kernel bug

[Yoann Padioleau]

Hi cinap,

Would it be possible to change a bit the 9front mercurial repository so that
it can work on MacOS filesystem. 

I get some:
abort: case-folding collision between sys/lib/troff/font/devutf/charlib/lH and sys/lib/troff/font/devutf/charlib/LH

when hg pull; hg update.

I can understand the hate for non plan9 OS but it would be nice :)

On Jun 5, 2014, at 9:15 PM, cinap_lenrek@felloff.net wrote:

> no. it just makes the kernels malloc arena limit a bit smaller than
> it should be.
> 
> --
> cinap
> 

Re: [9fans] other kernel bug

[erik quanstrom]

On Mon Jun  9 21:02:01 EDT 2014, pad@fb.com wrote:
> Hi cinap,
>
> Would it be possible to change a bit the 9front mercurial repository so that
> it can work on MacOS filesystem.
>
> I get some:
> abort: case-folding collision between sys/lib/troff/font/devutf/charlib/lH and sys/lib/troff/font/devutf/charlib/LH

we tried that with the original nix+googlecode gang, and it
was trouble.  Kill vs. kill, etc.

a lot of time was spent trying to overcome the shortcomings of
unrelated systems.  i didn't think it was a good use of resources.

i think it would be easier to set up your file system to be case
sensitive.

- erik

Re: [9fans] other kernel bug

[Ethan Grammatikidis]

On Tue, Jun 10, 2014, at 02:07 AM, erik quanstrom wrote:
> On Mon Jun  9 21:02:01 EDT 2014, pad@fb.com wrote:
> > Hi cinap,
> >
> > Would it be possible to change a bit the 9front mercurial repository so that
> > it can work on MacOS filesystem.
> >
> > I get some:
> > abort: case-folding collision between sys/lib/troff/font/devutf/charlib/lH and sys/lib/troff/font/devutf/charlib/LH
>
> we tried that with the original nix+googlecode gang, and it
> was trouble.  Kill vs. kill, etc.
>
> a lot of time was spent trying to overcome the shortcomings of
> unrelated systems.  i didn't think it was a good use of resources.
>
> i think it would be easier to set up your file system to be case
> sensitive.

*nods* i have to second this. you can set partitions case-sensitive in
mac os x. it's been a while, but i think that's what i did with my user
data partition. i heard if you set the root case-sensitive it breaks
adobe products but not much else.

--
You can't have your fun and eat it too.

Re: [9fans] other kernel bug

[Kurt H Maier]

Quoting Yoann Padioleau <pad@fb.com>:

> Hi cinap,
>
> Would it be possible to change a bit the 9front mercurial repository so that
> it can work on MacOS filesystem.
>
> I get some:
> abort: case-folding collision between
> sys/lib/troff/font/devutf/charlib/lH and
> sys/lib/troff/font/devutf/charlib/LH
>
> when hg pull; hg update.
>
> I can understand the hate for non plan9 OS but it would be nice :)
>


your operating system is broken.  fix that.

khm

Re: [9fans] other kernel bug

[cinap_lenrek]

thats a good one. this is not a problem with the repository. this
is a problem with this troff compontent assuming a case sensitive
filesystem. i cant fix it without changing troff. also, this isnt
the only case. i can't for example check out on windows because
we have /bin/aux and aux is a special name on dos.

the repository files itself use a mangeling scheme. but not whats
checked out for obvious reasons.

making all files in plan9 comply to all the filesystem restrictions
(what about unicode?) of all foreign operating systems out there
seems futile.

--
cinap

Re: [9fans] other kernel bug

[cinap_lenrek]

maybe the plan9-theme-for-unix projects have a solution?

if you have a patch that isnt too disruptive (removing troff
doesnt count) i'd be willing to commit it but i'm not undergoing
the work to puzzle arround with macosx problems.

--
cinap