Sebastien, the goal is to have only one implementation at the end (lets call it SUNWposix-core), one which is a maintained, modern, very fast, conforms to POSIX, SUS, passes UNIX branding requirements (some people have voiced concerns about this, I can say as current project lead in charge that this is nothing to worry about as we indent to pass all tests and requirements required by the UNIX brand), implements commonly used BSD and GNU features and supports a wide range of systems from very small 16 MB ARM embedded machines scaling up to very large servers with 16 TB or more.
Olga On Wed, Apr 21, 2010 at 4:52 PM, Sebastien Roy <[email protected]> wrote: > On 03/31/10 12:19 PM, Garrett D'Amore wrote: >> >> The project team has decided to change the proposal to remove the >> contentious builtins for /usr/gnu. Instead, only /usr/bin and >> /usr/xpg4,xpg6 utilities are being provided as builtins. As these >> utilities will hopefully one day be converted to use the same underlying >> libcmd interface, this should not be contentious. >> >> I'm restarting the timeout for one week from today (timeout expires >> April 7). The revised spec follows. > > Given that this case is building upon pre-existing built-in architecture, I > don't have any issues specific to this case that should hold it up. +1 > > That said, I think one thread of substance from the lengthy discussion this > case spawned relates to the duplicity of code between the commands and their > built-in equivalents. This is more a commentary of the implementation of > built-ins in general, and not of the specific built-ins introduced by this > case. Having architecture introduced to allow a shared implementation (as > Garrett hopes will be the case with libcmd above) would be a good thing. > > -Seb > > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ [email protected] \-`\-'----. `'-..-| / Solaris/BSD//C/C++ programmer \ |-..-'` /\/\ /\/\ `--` `--` _______________________________________________ opensolaris-arc mailing list [email protected]
