Glenn Fowler writes:
> from the ast/ksh perspective workarounds are a way of life
Indeed. And the same is true for many other open source projects.
I'm not _completely_ ignorant. :-/
> even if vendor bug fix turnaround is 6 months it may
> take users years to upgrade to the fix
> and we would need 1 head count to keep track of all the bugs
> among all the vendors
Yep; clearly understood.
I was addressing the project team that is integrating this into the ON
consolidation of Solaris. The requirements on that team are distinct
from the issues faced by the broader open source project.
And it doesn't bother me at all that the open source project (as
distinct from the project team integrating into Nevada ON) may need to
provide special logic to work around problems in older releases,
particularly those where we're no longer delivering features or
regular updates.
> we'll be happy to report problems and workarounds encountered building on ON
> interested parties can translate those into official bug filings
> and when the fix finally rolls back around the iffe configuration
> workarounds will yield to the fix
OK.
> so I have access to solaris { 8 9 10 11 } machines
> how can I tell if any of them are ON?
I can't parse that request. But I think the answer is "all."
ON is a consolidation. The Solaris build process is made up of
multiple consolidations -- X, ON, Install, Admin, and many others.
Each consolidation delivers bits (in the form of packages) to
something called the "WOS." The WOS is (essentially) what constructs
the DVD/CD images that get the "Solaris" label on them.
Neither a machine nor a particular release is identifiable a
consolidation.
For "consolidation," you might reasonably substitute the word "source
repository." It's not quite the same thing, but it's close enough.
> I re-read the posix_spawn() standard and it is worded to
> allow successful return to the caller, with a valid pid,
> even when the executable encounters an exec error
> in that case exit status 127 (normally "not found")
> means "a fork or exec error", and the caller cannot
> retrieve the real errno
Yes, I see the apparent spec holes.
That doesn't mean that the current situation is really acceptable.
Posix_spawn is, as best I can tell, designed for just this sort of
application. If it doesn't work, and users are forced to work through
alternatives or special hacks to get it to work as needed, then that
sounds like evidence of a serious problem. We can't let features that
are unusable for the intended purpose rot in the source base.
It _may_ mean that someone needs to enhance that function. It could
possibly mean working with the standards folks to get the holes fixed.
It could even mean that posix_spawn is not intended for use like this
and that the holes are just fine (though I don't see how that's
possible). We won't really know the extent of the issue until a bug
describing ksh93's difficulties is filed and evaluated.
I don't think the standards are a suicide pact. ;-}
> but I think quality of implementation should push
> posix_spawn() implementers to find a way to make posix_spawn()
> fail immediately on exec error -- with real vfork this is possible
> we've done it in the spwanveg() implementation that uses real vfork/exec
So, then, let's see to it that posix_spawn is fixed in Solaris.
--
James Carlson, KISS Network <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
