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.) > 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. 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. > 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. (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 ...) Plus, you'd confuse the heck out of administrators. Perhaps even more so than we did with our "ipnodes" stuff. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
