Can i.services be optimized? six fork/exec's per entry seems a bit
excessive. Maybe a rewrite into a nawk script could be helpful. (It
seems like maybe we would like a way for packages to be able to use more
powerful scripting languages during install. This is probably a much
simple problem to solve in perl.)
Anyway, I think my first best answer would be to optimize i.services if
possible. Creation of a new services.iana seems kind of weird/strange,
and a likely source for customer calls. I'd prefer to keep it the way
it is if possible.
-- Garrett
Nicolas Williams wrote:
> I'm working on a fix for:
>
> 4511649 /etc/services should contain entries for well-known services
>
> It sounds simple. It should be simple.
>
> Alas, it's not.
>
> Producing a merged services file is a one-time task consisting of manual
> and scripted editing of the port-numbers file from IANA to remove
> extraneous non-services(4) format text, followed by merging the result
> with $SRC/cmd/cmd-inet/etc/services.
>
> So far so good, no big deal.
>
> 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.
>
> I'd be adding 10,316 entries to /etc/services.
>
> The first upgrade to install the new services file would need about two
> seconds to run i.services. The second upgrade would need about a minute
> and a half. (The actual time, of course, will vary according to what HW
> you're running and how much contents the customer has added to
> /etc/services.)
>
> That covers upgrade in the Solaris sense. Since I'll be fixing this
> only for Solaris Nevada, and since the future is OpenSolaris, maybe I
> shouldn't worry at all about that minute and a half.
>
> 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).
>
> 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'm inclined to keep things simple and just add the IANA content to
> /etc/services.
>
> Advice?
>
> Nico
>
_______________________________________________
networking-discuss mailing list
[email protected]