[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] libnbd



On Mon, Apr 29, 2013 at 01:28:02PM +0200, Wouter Verhelst wrote:
> On 29-04-13 11:45, Goswin von Brederlow wrote:
> > On Thu, Apr 25, 2013 at 06:39:21PM +0200, Wouter Verhelst wrote:
> [...]
> >> That's a lot of stuff to do for a "little" function. The current code
> >> just has the function which implements the first bullet point in the
> >> above list call the next function. That works, I suppose, but it's
> >> extremely non-flexible.
> >>
> >> If we're going to allow people to replace (or disable?) some of that
> >> functionality, they can't be directly calling eachother anymore. I think
> >> a state machine there is the most flexible way to make that possible
> >> (although I could certainly be wrong about that).
> > 
> > The "little" function handle_request() would be, in your case, start a
> > complex state machine. The implementation of the state machine can
> > have before/after hooks and replacable states and such. That is all fine.
> > 
> > But I would like to see a clear seperation of the select loop and
> > protocol parsing and handling requests.
> 
> Of course, that's the whole plan.
> 
> In my view, the select loop would:
> - Read a request header into a struct nbd_request, and parse it (i.e.,
> call ntoh* on the right variables of the struct that we read the header
> into)
> - Figure out if the request is followed by data; if so, read that data
> from the socket
> - Inform the correct state machine that some data is available, and move
> on to the next request

The "inform" would be the handle_request() call in my suggestion. :)

MfG
	Goswin



Reply to: