Re: [RFC]: Provide IEEE 1003.1-2003 ulimit()

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

Jeff Johnston wrote:

> 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.

I have looked at the EL/IX specification in view of RTEMS and it is
close.  But no one has ever cared enough about truly evaluating
RTEMS in terms of EL/IX and trying to see what was missing in RTEMS,
where EL/IX might have made mistakes, etc..

Nothing against EL/IX in particular, but I have seen a lot of
UNIX-ish specifications over the past 15 years and what a UNIX
user needs and what an embedded user needs are not exactly the
same.  We were involved in the POSIX profiles standardization
effort and that took years to get a document.

I have never heard of someone requiring getrlimit() to
write software for or port software to RTEMS.  That leads me to
believe that it isn't a critical requirement to embedded users
or even required to port desirable software to an embedded
platform.

With that said, if you do put it in an optional directory and
define the glue to OS routines, then RTEMS might support it
anyway because it is a standards defined routine.  It just isn't
one a many embedded applications are going to use.  But that
hasn't stopped us from supporting a lot of what I would consider
marginally useful system calls.

> -- Jeff J.

--
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985