[ECOS] comment about header files

[ECOS] comment about header files

[tsmith]

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 :)]

Re: [ECOS] comment about header files

[Jonathan Larmour]

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

Re: [ECOS] comment about header files

[Gary Thomas]

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 :-)

RE: [ECOS] comment about header files

[tsmith]

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?)

Re: [ECOS] comment about header files

[Jonathan Larmour]

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