seth Nimbosa <darth.seri...@gmail.com> wrote:
> I think the general idea is to get to a minimum criteria as basis for wider
> collaboration. We have to start small and manageable and agreeable. Then
> others will follow if they see the benefits of that working together for a
> healthier code and healthier community guidelines, then there will be lower
> barriers for participation, more consensus-building and pooling together
> the best solutions out there.
It is more than a minimum criteria, we need (as mentioned yesterday) an opening
towards OpenSolaris goals that do not prevent collaboration because of
artificial limitations in a single development branch.
For me, it is important that OpenSolaris keeps the ability to be ported to
embedded systems. This reqires some decisions made by Sun and others made by
Illumos to be reverted. So the following requirements are important:
- Keep support for 32 bit kernels (at least for one CPU target)
- Keep support for a UFS root filesystem
- Keep support for /usr being on a different FS than /
- Allow it to be on a tiny system where you cannot afford the monster
ksh93 to allocate several MBs on a tiny root FS. This requires support
for the Bourne Shell for all scripts that need to be run before /usr
is mounted, which means to fix 6 shell scripts modified by Sun in
spring 2010.
Other criteria are support for SVr4 package meta data. This may need to add
support for specific SVr4 meta data that did not exist in 2010 already. Note
that I did enhance the SVr4 packaging for SchilliX-ON already and there will
be further enhancements in the future. There is e.g. a plan to add some high
level functions seen on IPS to be added to "pkgadm". There is also a plan to
allow longer names and to add category based entries in the metadata. The
latter is partially already in SchilliX-ON.
We need an ABI definition for OpenSolaris.
We should have an architecture commitee that should at least give a base for
simple additions that do not cause incompatibilities. To make some examples
from the SchilliX-ON development:
- grant the libraries to run e.g. star and the new enhanced Bourne Shell
to be present. This is e.g. /lib/libschily* /lib/libshedit*
/lib/libxtermcap*. These libraries are in SCHILYsystem-library-schily*
SCHILYsystem-library-schily-root and SCHILYsystem-library-schily are now
part of the basic system dependencies, so you cannot install a system
without it.
- Add POSIX enhancements like the %r printf format that I am currently
proposing for the next POSIX version. The first implementation already
exists and will appear soon on SchilliX-ON (after the discussion on
the standard commitee did settle).
- Add syscall enhancements like a planned method to allow a process to
aquire enhanced privileges without the need for a exec*() call.
Since 24 months, cdrtools may be installed non-suid-root without
the need for the current wrapper scripts. This is currently implemented
by a re-exec in cdrecord/cdda2wav/readcd, but this could be done by a
new function to the privsys() call to avoid a re-exec.
I am sure that other ON development branches have own code too, that might be
of general interest if it is not in conflict with a previous ABI.
> I am inviting Alasdair, Peter Tribble, Jörg Schilling and Martin Bochnig to
> discuss this and find the best way forward in creating this smaller circle
> to create greater trust and more support from within the
I tried this already several times in the past, but maybe it is better to have
a moderator that is not involved in an own development branch.
To be able to start, we need to talk about what we are doing and be open for
the contraints that need to be met in order to permit a collaboration.
e~A
-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com
