Re: [RFC][PATCH] nbd driver for 2.5.72

[viro@parcelfarce.linux.theplanet.co.uk]

On Sat, Jun 21, 2003 at 10:39:12AM -0600, Lou Langholtz wrote:
> >Why not put these into nbd_device?
> >
> I'd considered that and I'm reconsidering it again now. Not convinced 
> which way to go... Putting something as large as struct request_queue 
> within the nbd_device seems unbalanced somehow. Then again, until 2.5 
> the request_queue was typically shared by multiple devices of the same 
> MAJOR so part of the way the code is has to do with the legacy code. 
> Like the nbd_lock spinlock array and the struct request_queue queue_lock 
> field. Along the lines you're pushing for, why not have struct 
> requests_queue's queue_lock field then be the spinlock itself instead of 
> just being a pointer to a spinlock???

Because often that lock protects driver-internal objects that are used
by all queues.

Prefered variant (actually, we'll have to do it in 2.5 anyway) is to
allocate request_queue dynamically.  Just put a pointer to it into nbd_device.

BTW, could you please kill the ..._t silliness?  There is nothing wroung
with using 'struct nbd_device' directly.
 
> >>+static uint32_t request_magic;
> >>   
> >>
> >
> >???  htonl(NBD_REQUEST_MAGIC) is perfectly OK in the place where you
> >use it and more likely than not will give better code.
> >
> > 
> >
> >>+static uint32_t reply_magic;
> >>   
> >>
> >
> >Ditto.
> >
> What's wrong with having an explicit cache of this value that we can 
> rest assured doesn't in the worst case get compiled into multiple calls 
> to the htonl code?? Possible waste of one 4 byte memory location in the 
> worst compiler case or is there another problem?

htonl() honours constants.  If it doesn't, we are in for much more serious
problems, simply because a lot of codepaths in networking are using it.
A lot.  IOW, you are obfuscating code for no good reason (and add an extra
memory access, thus giving actually worse code - it's not an optimisation
at all).