From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 69EF121FAC for ; Sun, 12 May 2024 16:50:13 +0200 (CEST) Received: from duke.felloff.net ([216.126.196.34]) by 9front; Sun May 12 10:48:09 -0400 2024 Message-ID: Date: Sun, 12 May 2024 16:47:52 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: virtual grid metadata method Subject: Re: [9front] [PATH] error()/waserror() for userspace Reply-To: 9front@9front.org Precedence: bulk Some notes and questions: 1) privmalloc() should probably round the size up to 8 bytes, so we maintain struct alignment. 2) We need a manpage for privmalloc() describing the zeroing semantics on fork(). 3) Should privmalloc() nil instead of abort()? arguments pro/con? 4) maybe should introduce privmalloc() as a separate commit. this has alot of impact as you'd want to implement nsec() and atexit() using this new mechanism. doing that first is a way to ensure that the design is sound. also, we have to think about backwards compaty. if you run a old kernel that has no "private" segment trype. should atexit() fall back on global pid tagged array? ect. 5) theres no range check in pusherrlab(). It just silentely corrupts memory. 6) Maybe call Errlab to "Errlabs" because it represents multiple error labels. In the kernel, we have Label struct representing a single "jumpbuf" and it is put in the Proc struct as Label errlab[NERR]. 7) Is 32 labels good enougth? For libthread, we could even just allocate the labels dynamically as we control the whole thread. a jmp_buf costs you like 16 bytes, which means the thread gets bloated by 512 bytes, even if we never use error(). 8) For porting programs using privmalloc(), how'd we be able to emulate these semantics? Is it possible? 9) Should we provide a noteerror(ureg) function, so you can raise an error from a note handler? -- cinap