public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] comment about header files
@ 2001-07-26  6:26 tsmith
  2001-07-26 10:31 ` Jonathan Larmour
  0 siblings, 1 reply; 5+ messages in thread
From: tsmith @ 2001-07-26  6:26 UTC (permalink / raw)
  To: ecos-discuss

briefly trying to use the header files supplied with eCos has led me to the conclusion that they are a bit of a mess.

sys/param.h is literally unincludable as its just been plonked in with no thought.

i've alredy pointed out select() being in network.

there is also a lack of 'standard' (at least in my eyes) defines such as CLSIZE and getdtablemax() for example.

not that i'm going on but if anyone has time it would make eCos application developers lives much easier if the header files were tidied up as well as helping further development.

having a tangle of header files in code is stupid

[end of complaints :)]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ECOS] comment about header files
  2001-07-26  6:26 [ECOS] comment about header files tsmith
@ 2001-07-26 10:31 ` Jonathan Larmour
  2001-07-26 16:15   ` Gary Thomas
  0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Larmour @ 2001-07-26 10:31 UTC (permalink / raw)
  To: tsmith; +Cc: ecos-discuss

tsmith@megaroms.co.uk wrote:
> 
> briefly trying to use the header files supplied with eCos has led me to the conclusion that they are a bit of a mess.
> 
> sys/param.h is literally unincludable as its just been plonked in with no thought.

That comes from the net stack. Anything that comes from the BSD net stack
is a problem actually. This is why the net stack was considered an optional
add-on - there are lots of yucky bits in it.

But why do you want <sys/param.h> anyway? I don't think there's any public
APIs there people should be using (things like NOFILE are a bad idea).

> i've alredy pointed out select() being in network.

Fixed, fear not! It'll show up in anon CVS shortly.
 
> there is also a lack of 'standard' (at least in my eyes) defines such as CLSIZE and getdtablemax() for example.

Well, AFAIK Linux doesn't even have those so I don't know how standard they
are.
 
> not that i'm going on but if anyone has time it would make eCos application developers lives much easier if the header files were tidied up as well as helping further development.
> 
> having a tangle of header files in code is stupid

Agreed.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ECOS] comment about header files
  2001-07-26 10:31 ` Jonathan Larmour
@ 2001-07-26 16:15   ` Gary Thomas
  0 siblings, 0 replies; 5+ messages in thread
From: Gary Thomas @ 2001-07-26 16:15 UTC (permalink / raw)
  To: Jonathan Larmour; +Cc: ecos-discuss, tsmith

On 26-Jul-2001 Jonathan Larmour wrote:
>> there is also a lack of 'standard' (at least in my eyes) defines such as CLSIZE and
>> getdtablemax() for example.
> 
> Well, AFAIK Linux doesn't even have those so I don't know how standard they
> are.
>  

They aren't very standard at all - in fact they are very much Unix (BSD) legacy.

>> not that i'm going on but if anyone has time it would make eCos application developers lives
>> much easier if the
> header files were tidied up as well as helping further development.
>> 
>> having a tangle of header files in code is stupid
> 
> Agreed.

We all have to live within our means.  In this case, when we imported the 
BSD networking code, the [initial] decision was to try and keep the code 
as pristine as possible.  This decision was based on the hope/anticipation
of keeping up with the BSD networking as a separate, maintainable component
with influences from outside.  However, it also meant living with their 
include files, however ugly.

If anyone wants to rewrite all of those headers, and validate the stack
afterwards, feel free to do so.  After all, this is open source :-)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ECOS] comment about header files
  2001-07-27  1:00 tsmith
@ 2001-07-27  6:18 ` Jonathan Larmour
  0 siblings, 0 replies; 5+ messages in thread
From: Jonathan Larmour @ 2001-07-27  6:18 UTC (permalink / raw)
  To: tsmith; +Cc: ecos-discuss

tsmith@megaroms.co.uk wrote:
> 
> just a couple of points:
> 
> agreed the BSD net stuff is an 'extra'
> 
> quoting from my linux man page for getdtablesize
> 
> "getdtablesize  is  implemented  as  a library function in DLL 4.4.1.  This function returns OPEN_MAX (set to 256 in Linux 2.0.23) if  OPEN_MAX was  defined  when  the library was compiled."
>
> and does seem to be implemented by linux, but again I agree about non-standardness (is that a word?)

The more standard function is to use sysconf with _SC_OPEN_MAX. We
certainly don't provide it, and don't expect to since there is a standard
alternative.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: [ECOS] comment about header files
@ 2001-07-27  1:00 tsmith
  2001-07-27  6:18 ` Jonathan Larmour
  0 siblings, 1 reply; 5+ messages in thread
From: tsmith @ 2001-07-27  1:00 UTC (permalink / raw)
  To: ecos-discuss

just a couple of points:

agreed the BSD net stuff is an 'extra'

quoting from my linux man page for getdtablesize

"getdtablesize  is  implemented  as  a library function in DLL 4.4.1.  This function returns OPEN_MAX (set to 256 in Linux 2.0.23) if  OPEN_MAX was  defined  when  the library was compiled."

and does seem to be implemented by linux, but again I agree about non-standardness (is that a word?)



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2001-07-27  6:18 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-26  6:26 [ECOS] comment about header files tsmith
2001-07-26 10:31 ` Jonathan Larmour
2001-07-26 16:15   ` Gary Thomas
2001-07-27  1:00 tsmith
2001-07-27  6:18 ` Jonathan Larmour

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).