Hi Hendrik,
> > > 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.
problem is that either we introduce a new abstraction or we figure this
out magically. Breaking the API like this is not a good idea.
So if we go for FdPacketOBEX or something it might be a possible option,
but breaking FdOBEX API is not an option.
Regards
Marcel
--
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
