If optimizing i.services is not a reasonable task, how about just
emitting a message, filing a P4 bug to improve the performance of
i.services, and worrying about the 1.5 minutes later?
-- Garrett
Nicolas Williams wrote:
> 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]
