This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: [RFC]: Provide IEEE 1003.1-2003 ulimit()
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: Nicholas Wourms <nwourms at netscape dot net>
- Cc: newlib at sources dot redhat dot com
- Date: Tue, 06 Jan 2004 14:38:05 -0500
- Subject: Re: [RFC]: Provide IEEE 1003.1-2003 ulimit()
- References: <bs259k$nqu$1@sea.gmane.org> <3FE75B2E.7030601@redhat.com> <3FE76A37.5050200@netscape.net>
Nicholas Wourms wrote:
Jeff wrote:
Nicholas,
This sounds similar to the other BSD submission you made. If your
code requires any BSD-specific syscalls or interfaces (i.e. any
syscall/interface that is not part of the generic newlib), then the
code must be put in sys/bsd. You will have to create this
directory. This is along the lines of sys/linux. Newlib is
designed to work for embedded platforms, most without an OS. An
example of an exception to the rule is the 64-bit I/O routines that
are shared among a number of systems that have 64-bit syscalls. It
is configurable and is needed to coexist properly with the regular
I/O routines.
-- Jeff J.
Jeff,
Well this isn't a "BSD"-specific submission, as the subject points
out, it is a ratified POSIX standard. As for my prior submission, I
working on making it usable by everyone. However, for the record, I'm
doing all this for Cygwin, not BSD, I just happen to make use of their
source if it is appropriate to do so. Yes, I did use a syscall -
getrlimit - but I was careful to make sure it was widely avaiable on
both embedded and regular platforms. That syscall, according to the
EL/IX-1.2 API specification, is a level 1 requirement, which, if I
understand correctly, means it is supposed to be supported on
linux/embedded, eCos, Vxworks, pSOS, RTEMS, etc. Also, getrlimit can
found on just about any other major unix out there, just punch it in
google (AIX, Solaris, SunOS, UnixWare, OSF/1, Tru64, HP/UX, BSD,
Darwin, Linux, to name a few...). Since ulimit can be used by a
majority of the OS's newlib compiles for as well as most of the
popular embedded platforms, I don't understand why this is a problem.
The problem is that the majority of supported newlib configurations are
"not" EL/IX compliant. A simple compromise would be to follow the
example of the posix_dir in configure.host. Add a new gen_dir setting
and have it set to gen for systems that can and want to use the code there.
-- Jeff J.