rtems_bsdnet_fdToSocket()

[Till Straumann]

Chris Johns wrote:
> Till Straumann wrote:
>> OK - then we're on the same page. I thought you didn't like the idea of
>> knowledge about a file type built into a 'iop'.
>
> Sorry I was not clear.
>
>> If the type is encoded
>> in 'flags' or in a dedicated field doesn't matter too much, IMHO since
>> it would be accessed via a macro or inline, i.e., the user setting or
>> querying the type wouldn't have to know how/where is is kept.
>>
>> rtems_libio_iop_set_type(iop, type)
>>
>> type   rtems_libio_iop_get_type(iop)
>>
>
> I am fine with hiding the detail. Specific flags is limiting so how 
> about 4bits of the flags as the type ?
>
> What types should we have ?
>
> If we break up the flags to have the 4bits can an area set aside for 
> internal flags ?
I'm afraid this won't fly. The libio layer indeed
has no knowledge of the file type - only file systema
have. I don't see how the type field in the iop
would be set (for nodes living in an ordinary
file system, that is -- fdToSock and makeFdForSocket
would take care of it for sockets which is why
we are having this discussion -- and unless
the code for all filesystems is overhauled to
set the type field in iop).

The 'fdToSock' and 'makeFdForSocket' routines
are IMO kludges to work around limitations of
the libio/filesystem design.

'ordinary' system calls operating on file descriptors
are dispatched by the filesystem code to the
attached handlers and the handlers know how
to interpret the data attached to iop->data1 etc.

This doesn't work for most socket operations
(bind, getpeername, ...) since there are no corresponding
callouts in the file handler table. If there were,
'bind()' would simply be coded

if ( ! iop->handlers.bind_handler ) {
    errno = ENOTSOCK;
    return -1;
}
return iop->handlers.bind_handler(iop, ...);

and the 'bind' handler could be sure that
iop->data1 points to internal socket data
(since an plain file would have a NULL bind_handler)

Hence, I don't think there is a really clean
solution and we are back to square one:

1) we could mark a iop as 'special' for files
   which need special treatment. This essentially
   works as discussed: set a few bits in 'flags'
   aside or create a new field in the iop.
   We just don't call this 'file type' in the
   strict sense but 'kludge markers' which
   allow system calls like 'bind' to identify
   the kind of object the iop is pointing to.

2) we accept that 'fdToSock' and 'makeFdForSocket'
   are kludges. Let 'makeFdForSocket' store
   the 'handlers' argument in static variable
   (which is checked by fdToSock to make sure
   an 'fd' is a socket) and assert every subsequent
   execution of makeFdForSocket is passed the
   same 'handlers'. This way, everything could
   be encapsulated in the libio_sockets.c kludge
   w/o the need to expose another global var.

I think neither variant is particularly pretty
but either would be better than what we have now.

I believe ATM I tend towards 2) -- it doesn't
make libio_sockets.c worse than it already is
and confines any changes to that code. And it
does fix a problem just by adding a few lines
to libio_sockets.c

T.
>
> Regards
> Chris