Am Montag, 20. Juni 2011, 18:43:10 schrieb Marcel Holtmann:
> Hi Nami,
>
> > include/openobex/obex_const.h | 4 ++++
> > lib/fdobex.h | 1 +
> > 2 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/openobex/obex_const.h
> > b/include/openobex/obex_const.h index cb7afeb..8acee91 100644
> > --- a/include/openobex/obex_const.h
> > +++ b/include/openobex/obex_const.h
> > @@ -302,6 +302,10 @@ enum obex_rsp_mode {
> >
> > OBEX_RSP_MODE_SINGLE = 1, /**< single response mode (SRM) */
> >
> > };
> >
> > +enum fdobex_transport_format{
> > + FDOBEX_MT_STREAM ,
> > + FDOBEX_MT_SEQPACKET
> > +};
>
> can I ask again why we should be doing this. Especially for the FdOBEX
> transport this is pointless. You are getting a file descriptor in the
> first place. It does not have to be a socket.
>
> And in the case this is really a socket, then you can just use SO_TYPE
> to read the current type of the socket.
>
> If it is not a socket, then it needs to treated as stream anyway.
No. Ever tried that on the linux USB gadget implementation in Linux? If a FD
is not pointing to a socket, it can still point to a device file of whatever
kind. You SO_TYPE won't completely help here. You can try any amount of
guessing but isn't it easier if the application just tells you? OTOH, the
application could just use a custom transport, then.
HS
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
