[ENBD] Re: ENBD Removeable Media Support

[Peter T. Breuer]

"Jason A. Pattie wrote:"
> Peter T. Breuer wrote:
> >Some progress ...
> >
> Cool! [...]
> >I'm slowly ramping up to ioctls which read data (those which write
> >always write what you think: an int). One problem is that the kernel
> >is full of places where peoplele have forgotten to make the right
> >declarations. I'll need lookup tables.

The tar at ftp://oboe.it.uc3m.es/pub/Programs/nbd-2.4.27pre1.tgz
has working support for all kinds of remote ioctls.

Caveats:

  1) you get to see the debugging printks and printfs when you use one

  2) the only ioctls it will accept are those that read or write data
     of less than or equal to 16 bytes in size. I know of at least one
     common 17 byte ioctl. This can be changed, of course.

  3) you must add the ioctls you want to a whitelist in nbd/ioctl.c (which
     should be a link to the nbd_ioctl.c file next to the nbd.c driver).

     This list contains a translation table which puts back information
     that kernel authors should have included in the ioctl id, but
     forgot, or got wrong.

     The principle is that an ioctl like BLKSSZGET, declared in fs.h,
     which is defined in the kernel as

         _IO(0x12,104)

     (arbitary type=12, arbitrary id=104)

     really should have been defined as

         _IOR(0x12,104,int)

     because the "R" tells me that the data is indirected - the
     argument will be an int* - and the "int" tells me the size of the
     indirected data. If you wanted a read/write datum, you would need
     _IOWR.

     The entry in the table in my ioctl.c is

       { BLKSSZGET,  _IOR(0x12,104,int), },

     with the kernel's value at left, and the "right" value at right.

Let me know if you need help fitting the parts together. It's a CVS
snapshot, rather than a tar of the source directory, and goodness 
knows if there are missing symlinks or not.

The only thing I've tested it on is "fdisk -l". Well, I figure if it
works for 4 bytes, it works for anything.

Peter