On Tue, Nov 19, 2013 at 2:19 PM, Wouter Verhelst <[email protected]> wrote:
>
>
> Op 19-11-13 02:43, Paul Clements schreef:
> >
> >
> > On Monday, November 18, 2013, Wouter Verhelst wrote:
> >
> > Op 18-11-13 23:17, Paul Clements schreef:
> > [...]
> > > Right, some rearrangement of the ioctls would be required
> too...we'd
> > > probably want alternate versions of SET_SOCK and DO_IT that are
> > > re-entrant (right now those will error on an already-configured
> > device,
> > > and they're doing some setup and teardown that is unneeded in the
> > > reconnect case).
> >
> > Since all this is a significant departure of the current API, I
> suppose
> > it would be good if there would be a way for the client to detect
> what
> > the currently-running kernel supports, without having to resort to
> > things like calling 'uname -r' (or equivalent in C code) or extensive
> > error handling based on "that ioctl isn't supported, so let's fall
> back
> > to previous API versions."
> >
> >
> > Anything specific that would make it easier from your perspective? One
> > thought is to have SET_FLAGS fail when an unknown flag is passed. Or
> > say a get_capabilities() type call?
>
> A get_capabilities() would be most useful, yes.
Anything besides supported flags that the client needs to know? Or are we
really maybe just talking about a GET_FLAGS ioctl or other (possibly sysfs)
advertisement of flags?
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Nbd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nbd-general
