On Mon, Jun 16, 2008 at 02:04:38PM -0400, James Carlson wrote: > Nicolas Williams writes: > > Now, in the process of doing that merge I realized that we have a merge > > script already: i.services. It's used during install/upgrade. It's a > > /bin/sh script that fork()/exec()s a lot of processes: up to six > > per-entry in the /etc/services file to be upgraded. > > There seems to be some missing information here. How hard would it be > to make the existing script faster by (for example) rewriting the meat > of it in nawk and avoiding all the exec-ing? > > (No, before anyone asks: ksh93 need not apply for the job here. It's > not on S9, which would make the use of it non-LU-compliant.)
I'm not entirely sure what I can rely on. The problem is that any changes made to i.services means testing upgrade from S9 (and whoever backports, if anyone does, would have to test upgrade from S8). Ouch. I'd much rather do John Levon's suggestion than optimize i.services. > > Or maybe I should because it could get backported. And maybe I should > > ask how we intend to support upgrade semantics for /etc/services in > > OpenSolaris (but that's a separate issue). > > Until this new OpenSolaris mechanism displaces the existing Nevada, I > don't think it would be responsible to ignore the problem. Right now, > Indiana and IPS are "just projects," and shouldn't dictate (or negate) > integration requirements any more or less than any other > non-integrated projects. OTOH, upgrade to SXCE/SXDE/any Nevada build is simply not supported. And likely never will be. (Technically upgrades between Nevada builds and SX* releases are not supported either, right?) So how is spending a large amount of time on cutting that 1.5 minutes down responsible, rather than irrelevant? Of course, part of the answer may be that just because such upgrades are not supported doesn't mean that noone does them (I do them). > So, if ignoring the issue is the preferred answer, then I'd say that > the integration of this RFE simply has a dependency on IPS integrating > first. See above. > > John Levon suggests that the files name service switch backend should > > use two separate services files: /etc/services (editable) and > > /etc/services.iana (not editable). > > I wouldn't do that. I seem to recall some swilly start-up scripts for > Java applications that grep needed things out of /etc/services -- > because Java inexplicably lacks getservent-family functions. And swill that would be. *sigh* > (How you > can claim to have TCP/IP support but lack basic functionality like > that is a mystery to me. I guess nobody does anything like real > networking there ...) Maybe everyone just hardcodes their port numbers (one has to anyways, in case the needed entries are not in /etc/services). > Plus, you'd confuse the heck out of administrators. Perhaps even more > so than we did with our "ipnodes" stuff. A comment in /etc/services might suffice. This is different from ipnodes, I think. The primary benefit would be that we'd commit to shipping the IANA registrations in a non-editable file, so you could rely on that contents, but you could still overwrite it. OTOH, yes, it does seem a bit odd. There are three name services databases where we could follow this tack: protocols, services and rpc. Of these only /etc/services is often modified, I doubt anyone ever needs to modify /etc/protocols, and we're the registry for ONC RPC programs. Nico -- _______________________________________________ networking-discuss mailing list [email protected]
