From owner-freebsd-rc@FreeBSD.ORG Thu Jan 13 02:27:21 2005 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 002B516A4CE; Thu, 13 Jan 2005 02:27:20 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C39E43D2F; Thu, 13 Jan 2005 02:27:19 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j0D2RCml008203; Thu, 13 Jan 2005 03:27:13 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E5DC84.60608@redesjm.local> Date: Thu, 13 Jan 2005 03:27:16 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Dejan Lesjak References: <1105321614.8452.54.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> <41E2DD07.6010607@redesjm.local> <200501121809.46129.dejan.lesjak@ijs.si> In-Reply-To: <200501121809.46129.dejan.lesjak@ijs.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: freebsd-rc@freebsd.org cc: freebsd-x11@freebsd.org cc: Eric Anholt cc: x11@freebsd.org cc: Jose M Rodriguez Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 02:27:21 -0000 Dejan Lesjak escribió: >On Monday 10 of January 2005 20:52, Jose M Rodriguez wrote: > > >>Dejan Lesjak escribió: >> >> >>>Other than that, I don't really know what would be the best way to handle >>>creation of this directories and haven't commented so far, but since I'm >>>already writing (mostly because I thought rc@ list should be CCed), here's >>>my opinion FWIW: the simplest seems to be a patch from Pawel Worach at >>>http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/0424 >>>45.html The benefit of using this simple approach is that it is simple (of >>>course :) and furthermore it only adds two more directories to /tmp at >>>startup as oposed to adding a file in /etc/rc.d. The difference being one >>>inode. But then again, perhaps I don't see all the implications and this >>>is too simple. >>> >>> >>The only I know is that this breaks rcNG writing rules. This is a >>little more than style. I think that goin more modular can't hurt. >> >> > >Well it is certainly an exception to how rcNG scripts are otherwise written, >but I don't see this as a bad thing. Creation of /tmp/.X11-unix and removal >of X lock file is already there as that seems the right place to do that. >Because of this it also seems natural (to me at least) to just add creation >of another dir there. I believe that having this in this script makes things >done at the right time - if one has configured to have /tmp directory cleaned >after boot, then things that should be recreated are recreated right after >that; if no other explicitly ordered cleaning up is done, these directories >(and a lock file) are still "cleaned" away and recreated with side effect of >having the right permissions. I'm not opposed of going modular, it just seems >that going modular for the sake of one directory is a bit of an overkill. > > > >>>Is there a real benefit in creating another rc.d script for doing this and >>>adding a knob to turn creation of these directories off? >>> >>> >>Even more critical paths in the boot process are controlled in this >>manner. Why not? >> >> > >As I said, I'm not opposed of doing it in this manner, I just don't see the >real need to create several additional scripts instead of changing two lines >in existing one that already takes care of cleaning (and preparing) /tmp >directory. > > > >>>Yes of course that would only solve things on -current and -stable, >>>however >>> >>> >>This was allways the main problem of solve this 'only base'. >> >> >> >>>there is already an UPDATING entry for this and we can always add a script >>>to be installed from a port that would take care of transition period >>>(probably as soon in dependency tree as possible, ie -libraries). >>> >>> >>There are PRs on this. I think that latest rcNG script (with perhaps >>some tweaks to work from ports) installed from Xorg libraries will be >>the better first step. We may make this install_script conditional when >>we have the problem solved in RELENG_5 base (test OS_VERSION) and lost >>this when RELENG_4 life cycle was expired. >> >> > >I'm aware of the PRs on this, I wanted to voice my opinion on the particular >problem of creating a directory /tmp/.ICE-unix with right permissions. >Allow me to ramble a bit more on these: If we go to "modular" way as you put >it, the we would have to add a script to create ICE-unix directory to, say, >-libraries ports and a script to remove lock file and X11-unix to -server >ports (more than two of them), while being careful not to let different >-server ports (as in server and nestserver...) step onto each others toes. Or >we could make additional port to only install one rc script. This is >certainly doable and would of course be more or less modular and could even >have knobs so one could choose if directories should be created/removed and >if lock file should be created/removed. I can't help but to think that this >would be using a bit tooo enormous hammer, that's why I still think a simple >solution proposed by Pawel Worach would be enough here. > >Dejan > > > > This is really a classic issue. Of course, you may choose, but what you like as a X11 hacker may not be so good for a rc hacker. In this aspect, going modular is more a system eng. need. It's not so direct think that a 'cleartmp' component is so vital for 'x11'. Also, as this is done in cleartmp, you don't have a checkyesno control over the code, as you have in common rcNG scripts. This is exec 'fully inconditional'. What I don't like is add even more params to this without control, but I don't have objetions to maintain the hack with the new needed support. -- josemi