Re: Compiling issues with enbd-2.4.35a and kernel2.6.25.9

"Also sprach uwe schmeling:"
  [ of end_that_request_last and its little nephews and nieces ]

> > Can you please check for me where it has gone? Or if it has gone.
> > 
> this is now living in blk-core.c but there is only a __end_that_xxx
> which is not exported anymore

Sigh. That is a big change. I'll need to see what to do about it.

BTW, you can probably make the newer 2.4.35 enbd_request struct equal
in size to the 2.4.30 enbd_request struct by adding a "special" field
in the newer struct at the point where it appears in the older struct.
Then recompile and see if the newer client now works with the older
server.

It would likely die horribly, taking your grandmother and pet rabbit
with. But maybe not.

> > You can't, unfortunately. The on-the-wire sizes and shapes of the
> > headers preceding data has likely changed between 2.4.30 and 2.4.35.
> > The enbd_request and enbd_reply structs are defined in include/enbd.h.
> > 
> > In 2.4.35a request is:
> > 
> > struct enbd_request {
> >   __u32  magic;
> >   __u32   type;
> >   __u32 handle;
> >   __u64   from;
> >   __u32    len;
> >   __u32  flags;
> >   __u64   time;
> >   __s64   zone;
> >   __u32  seqno;
> >   union {
> >        __u32 digest[4];
> >        struct { __u64 cmd; __u64 arg; } __attribute__ ((packed)) ioctl;
> >   } data;
> >   char dummy0[0];               /* end of data */
> >   char dummy1[0] __attribute__ ((aligned (64)));
> >                                 /* end of struct (padded) - 64B */
> > } __attribute__ ((packed)) ;
> > 
> > and in 2.4.30 it is:
> > 
> >   struct nbd_request {
> >     __u32  magic;
> >     __u32   type;                  /* == READ || == WRITE  */
> >     __u32 handle;
> >     __u64   from;                    /* 64 bit PTB 132 */
> >     __u32    len;                     /* 32 bit or ioctl code */
> >     __u32  flags;
> >     __u64   time;
> >     __u64   zone;
> >     __u32  seqno;
> >     union { __u32 digest[4]; } data;
> >     __u32 special;
> >     char dummy0[0];
> >     char dummy1[0] __attribute__ ((aligned (64)));
> >   }  __attribute__ ((packed)) ;
> > 
> > and those are slightly different lengths. 2.4.30 has a "special" field
> > that 2.4.35a lacks (it probably got fitted in to the data field over time).

Yadda. Add the special field into the 2.4.35a struct and see if it
flies.

> > A random grep shows:
> > 
> >   ./drivers/block/DAC960.c:        if (!end_that_request_first(Request, UpToDate, Command->BlockCount)) {
> >   ./drivers/block/floppy.c:       if (end_that_request_first(req, uptodate, nr_sectors))
> >   ./drivers/block/nbd.c:  if (!end_that_request_first(req, uptodate, req->nr_sectors)) {
> > 
> > etc. So send me your nbd.c file from the new kernel.

> thank you for the fast response. Attached you'll find the nbd.c. There
> are no longer any ll_ files in the kernel. If I can give you some more
> help, please let me know.

Great. I'll have a look at it, but with changes that big I'll have to
go get the whole kernel .. groan.

Peter