From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5d375e920704120856i3501d43aw6412b2b1ca0b48e3@mail.gmail.com> Date: Thu, 12 Apr 2007 17:56:26 +0200 From: Uriel To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Re: [sources] 20070410: % cat >/sys/lib/dist/changes/1176262206.1.txt << EOF In-Reply-To: <9ab217670704120832k37d6e734u7d2b7edd9a6e4be0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5247962e2f1f11c9b374c57d9a9a71db@cat-v.org> <5d375e920704120814x7df5749sd7b8524972878a85@mail.gmail.com> <9ab217670704120832k37d6e734u7d2b7edd9a6e4be0@mail.gmail.com> Topicbox-Message-UUID: 45661456-ead2-11e9-9d60-3106f5b1d025 On 4/12/07, Devon H. O'Dell wrote: > 2007/4/12, Uriel : > > > # uncomment the following for booting other systems > > > #ip/dhcpd > > > #ip/tftpd > > > > Shouldn't optional stuff like this go in cpurc.local anyway? > > Sure, but having it here gives a good idea for the kinds of things > that you would want to put into your cpurc.local. Then maybe we should provide a sample cpurc.local instead... > > > > + #if(! netstat -n | grep -v 17008 | grep -s il.*Listen) > > > + # aux/listen -q il > > [...] > > > + # cpu specific startup > > > + #if(test -e /cfg/$sysname/cpustart) > > > + # . /cfg/$sysname/cpustart > > > + > > > + #echo `{date} $sysname >>/sys/log/boot > > > > Why is all this commented out? > > There's no /cfg in the default distribution, for one. IL isn't really > used per default and isn't very inter-operable. Not sure why the > bootlog change would be; it seems like a good thing to have in there > by default. In either case it's giving good ideas for things you may > want / need in your cpurc.local. It tests for the /cfg stuff, so if it doesn't exist it should not be a problem (the code that checks for /cfg/$sysname/cpurc is already uncommented.) You might be right about IL, but it might not hurt to have it either, in any case I agree there should be a way to enable or disable it without touching the default cpurc. > > One thing I'm not sure of still is, if there is a cpurc.local, it may > want to implement some things dependent on e.g. what if you are > starting some client script that requires the network to already have > been initialized. This seems to be what you would end up putting in > your /cfg/$sysname/cpustart, We might want a /rc/bin/cpustart.local too? > > This changes seem to intend to allow local installations to override > > the default cpurc setup without having to edit it (and therefore get > > out of sync with sources and need to merge future changes by hand and > > so on), so I see little reason to leave 'alternative' sections > > commented out when the local and $sysname specific scripts can take > > care of that. > > We need to have something automatically create /cfg for peoples > fossils when they upgrade then. You can't just mkdir /cfg. Having /cfg by default might be a good idea, but I don't think it is a big deal as long as it is optional, I suspect most small networks can get by with cpurc.local and maybe a cpustart.local, and if you want /cfg, you can just create it and cpurc should take advantage of it automatically. > > And thanks dho for writing the summaries! Just one small complaint, > > could you fix the first line of the comments (specially because it is > > used by convention as subject for the emails)? > > I could. How is your script splitting them up though? I was assuming > that it used those lines to split each change. For some unknown reason russ refused to have the changes split on his end, which would be the ideal. I have a script that splits the daily changes file and puts them in sources, see for example: /n/sources/contrib/uriel/changes/2007/0410/ and then use that as input for the email notifications. If someone wants to get a single email per day, they can get a digest of plan9changes. To split I use some awk magic to detect text that is not indented, which is the comments that go over the diffs. See the end of /n/sources/contrib/uriel/plog for the (awful and fragile) details. > > Best wishes > > > > uriel > > If we really wanted to take care of these issues, it'd be worth > considering the creation of an rc system, but I'm not sure how much > fire that would cause in the community. Maybe, but for now I think fixing up what we got seems easy enough and might be good enough. uriel