This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: Move sys/time.h to isoinfra package
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Peter Korsgaard <jacmet at sunsite dot dk>
- Cc: ecos-patches at ecos dot sourceware dot org
- Date: Mon, 10 Jan 2005 19:47:27 +0000
- Subject: Re: Move sys/time.h to isoinfra package
- References: <87sm5afrkm.fsf@p4.48ers.dk>
Peter Korsgaard wrote:
Hi,
The following patch moves the sys/time.h header from the two BSD tcpip
packages to the isoinfra package (needed for the following
gettimeofday patch).
The isoinfra package is not meant to have implementation specifics in it.
It's meant to abstract that, so implementations can come from other packages.
It's not meant to be just a place for common code. It's meant to be
standards-based with "features" being implemented by potentially a numebr
of packages, which may have different requirements. For example one of the
(very very) long term goals I have is to port newlib to eCos, which would
require a different implementation of these headers. It would all be
infeasible if not for the isoinfra package.
Yes, there are exceptions, but those were accidental and should be gotten
rid of in due course.
The (abstract) contents of isoinfra's sys/time.h should be dictated
primarily by what POSIX 2004 <http://www.unix.org/version3/iso_std.html>
requires should be exported or supplied by that header, rather than any
particular implementation and its additional requirements. That's like most
of the isoinfra headers. Look at <time.h> in isoinfra as an example of what
should go there.
Not sure if this link works but it might:
http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/time.h.html
One thing that does make sense is reasonable default contents where the
requirements are part of the POSIX API (as per that URL) and the defaults
are reasonable for any implementation. But there should still be the
possibility of overriding them.
So to cut a long story short, what you are trying to achieve is fine, but
this isn't the right approach.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine