Re: [Nbd] libnbd
- To: Wouter Verhelst <w@...112...>
- Cc: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] libnbd
- From: Goswin von Brederlow <goswin-v-b@...186...>
- Date: Tue, 30 Apr 2013 10:55:58 +0200
- Message-id: <20130430085558.GB31101@...1266...>
- In-reply-to: <517E5942.9030600@...112...>
- References: <516FBEB3.3070806@...112...> <20130425121417.GB15210@...1266...> <517926C9.4000804@...112...> <20130425144930.GC15210@...1266...> <51795C39.80103@...112...> <20130429094559.GC6252@...1266...> <517E5942.9030600@...112...>
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: