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.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE 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 9295D22BF6 for ; Wed, 19 Jun 2024 22:39:27 +0200 (CEST) Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Wed Jun 19 16:38:31 -0400 2024 Received: from mimir.eigenstate.org (localhost [127.0.0.1]) by mimir.eigenstate.org (OpenSMTPD) with ESMTP id cb682e9e for <9front@9front.org>; Wed, 19 Jun 2024 13:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eigenstate.org; h= message-id:to:subject:date:from:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=hyYj+Srlw6fI EMfHnyDBE106Aes=; b=f8VsEMioUxFmSVyr9/FL+K2Ez+KLm2GAi6oHluaTwH6H gO6PbhM/dXmjIPd5a1HwqZ9vPnNxUFCpj9FnqmCLBqvvZNVnxqghaFpiDJlXrfFH p0GYswWrrbfnsmCdsLoRBB5jZ0HfaPZYAB6VklNcYlDk6uHjTIhw30MnFaG2Z7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eigenstate.org; h=message-id :to:subject:date:from:in-reply-to:mime-version:content-type :content-transfer-encoding; q=dns; s=mail; b=f186RY6JsVB0LF2uE0U D7B4GyLlxfD42RFaIpcC9fRiV/FluCWDsEoscXh16yyOR345VaBLavqlCxbgkeJm bid52ZgVwwX2kqL4QvDToMv1x+w+XfbS3iYhpAvUCIIbYSb2XsYF/mzICfBZmboO jdKyMcFQl6UMjeXm8khBC37s= Received: from chainsaw ( [172.56.164.235]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 838e3f08 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Wed, 19 Jun 2024 13:38:29 -0700 (PDT) Message-ID: <6CAF33B7FE1F7FEF16D4C5EFD83514A5@eigenstate.org> To: 9front@9front.org Date: Wed, 19 Jun 2024 16:36:29 -0400 From: ori@eigenstate.org In-Reply-To: <317F730505EE7FCCC0697ACCEFECC36F@smtp.pobox.com> 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: open-source STM HTTP CMS table shader map/reduce database Subject: Re: [9front] ramfs usage Reply-To: 9front@9front.org Precedence: bulk Hm. I'll talke a look at this; I wonder if it's too late to clean up the interaction of the flags. Probably :( Quoth me+unobe@fallglow.com: > I was looking at ramfs and noticed that the ordering of some flags > provided inconsistent behavior. For example: > > cpu% ramfs -s -m /n/foo > cpu% cpu% ls -l /n > d-rwxrwxrwx M 83820 david david 0 May 16 12:29 /n/foo > cpu% ramfs -m /n/boo -s > cpu% ls -l /n > d-rwxrwxrwx M 83788 david david 0 May 16 12:29 /n/foo > cpu% > > To address this, I think that -m should always add a mountpoint, > unless -i is used. > > I also noticed that: > > * a few of the (non-debugging) flags were not documented in the man > page: -b, -a, and -c to set the mount flags. > > * -i is mutually exclusive with -s, -S, and -m, -b, -a, and -c but > that isn't clearly spelled out. If -s, -S, and -m are used together, > that seems like a fatal error to me, but if -b, -a, -c are used, that > is an ignorable error that can be mentioned on stderr. For instance: > > cpu% ramfs -i -b > mount flags ignored when using -i: > cpu% ramfs -s -i > ramfs: -i cannot be used with -s, -S, or -m flag > cpu% > > * A sysfatal() error would never happen because mtpt is always > defined when srvname is not, and vice versa, because mtpt is set by > default and only unset when srvname is set. > > I offer the attached patch for consideration. > > From: Romano > Date: Thu, 16 May 2024 21:52:36 +0000 > Subject: [PATCH] ramfs: document usage and provide clearer usage errors > > > Allow -m to be used to set mountpoint when used with -s and -S, > of ordering. Document flags -b, -a, and -c; document interaction > between certain flags, and raise errors when mis-use occurs. > --- > diff 7089a0e8dc50d86dce93176d284e23f82e5d2bdf 0b55b43b99d97129a0ca0731243d1edc7bbbb6ae > --- a/sys/man/4/ramfs > +++ b/sys/man/4/ramfs > @@ -4,7 +4,7 @@ > .SH SYNOPSIS > .B ramfs > [ > -.B -Dipsu > +.B -Dipsubac > ] > [ > .B -m > @@ -15,30 +15,50 @@ > .I srvname > ] > .SH DESCRIPTION > +.PP > .I Ramfs > -starts a process that mounts itself (see > -.IR bind (2)) > -on > -.I mountpoint > -(default > -.BR /tmp ). > +implements a file tree which keeps all files in memory. > +Initially the file tree is empty. > +.PP > The > .I ramfs > -process implements a file tree rooted at > -.IR dir , > -keeping all files in memory. > -Initially the file tree is empty. > +process mounts the > +.IR mountpoint (or > +.B /tmp , > +if not provided) > +with the mount flags > +.B MREPL and > +.B MCREATE . > +The mount flags can be set explicitly > +using > +.B -b , > +.B -a , and > +.B -c , > +corresponding respectively to the flags > +.B MBEFORE , > +.B MAFTER , or > +.B MCREATE (see > +.IR bind(2)). > .PP > The > -.B -D > -option enables a trace of general debugging messages. > +.B -p > +flag causes > +.I ramfs > +to make its memory `private' > +(see > +.IR proc (3)) > +so that its files are not accessible through the debugging interface. > .PP > The > +.B -D > +flag enables a trace of general debugging messages. > +.PP > .B -i > flag tells > .I ramfs > to use file descriptors 0 and 1 for its communication channel > -rather than create a pipe. > +rather than create a pipe or mount at > +.IR mountpoint . > This makes it possible to use > .I ramfs > as a file server on a remote machine: the file descriptors 0 > @@ -47,15 +67,6 @@ > to the client machine. > .PP > The > -.B -p > -flag causes > -.I ramfs > -to make its memory `private' > -(see > -.IR proc (3)) > -so that its files are not accessible through the debugging interface. > -.PP > -The > .B -s > .RB ( -S ) > flag causes > @@ -62,17 +73,26 @@ > .I ramfs > to post its channel on > .B /srv/ramfs > -.RB ( /srv/ \fIsrvname\fR) > -rather than mounting it on > -.IR mountpoint , > +.RB ( /srv/ \fIsrvname\fR) , > enabling multiple clients to access its files. > -However, it does not authenticate its clients and its > +The flag also causes > +.I ramfs > +to not use the default > +.IR mountpoint > +.B /tmp , > +however it will use the mountpoint > +.IR mountpoint > +explicit;y set using the > +.B -m > +flag. > +.I Ramfs > +does not authenticate its clients and its > implementation of groups is simplistic, so > it should not be used for precious data. > .PP > The > .B -u > -option permits > +flag permits > .I ramfs > to consume as much memory as needed; > without it, > @@ -86,4 +106,5 @@ > .SH SOURCE > .B /sys/src/cmd/ramfs.c > .SH "SEE ALSO" > -.IR bind (2) > +.IR bind (2) , > +.IR proc (3) > --- a/sys/src/cmd/ramfs.c > +++ b/sys/src/cmd/ramfs.c > @@ -455,27 +455,40 @@ > { > char *srvname = nil; > char *mtpt = "/tmp"; > - int mountflags, stdio; > + int marg, mountflags, stdio; > > fs.tree = alloctree(nil, nil, DMDIR|0777, fsdestroyfile); > > - mountflags = stdio = 0; > + marg = mountflags = stdio = 0; > ARGBEGIN{ > case 'D': > chatty9p++; > break; > case 's': > + if(stdio) > + sysfatal("-s cannot be used with -i flag"); > srvname = "ramfs"; > - mtpt = nil; > + if(marg == 0) > + mtpt = nil; > break; > case 'S': > + if(stdio) > + sysfatal("-S cannot be used with -i flag"); > + if(srvname) > + sysfatal("-s cannot be used with -S"); > srvname = EARGF(usage()); > - mtpt = nil; > + if(marg == 0) > + mtpt = nil; > break; > case 'm': > + if(stdio) > + sysfatal("-m cannot be used with -i flag"); > mtpt = EARGF(usage()); > + marg = 1; > break; > case 'i': > + if(srvname || marg) > + sysfatal("-i cannot be used with -s, -S, or -m flag"); > stdio = 1; > break; > case 'p': > @@ -500,14 +513,14 @@ > usage(); > > if(stdio){ > + if(mountflags) > + perror("mount flags ignored when using -i"); > + > fs.infd = 0; > fs.outfd = 1; > srv(&fs); > exits(0); > } > - > - if(srvname == nil && mtpt == nil) > - sysfatal("must specify -S, or -m option"); > > if(mountflags == 0) > mountflags = MREPL | MCREATE;