From: viro@parcelfarce.linux.theplanet.co.uk
To: Lou Langholtz <ldl@aros.net>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@digeo.com>
Subject: Re: [PATCH] nbd driver for 2.5+: enhanced diagnostics support
Date: Tue, 24 Jun 2003 03:59:59 +0100 [thread overview]
Message-ID: <20030624025959.GO6754@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <3EF7B1C1.5040502@aros.net>
On Mon, Jun 23, 2003 at 08:04:49PM -0600, Lou Langholtz wrote:
> This third patch (for enhancing diagnostics support) applies
> incrementally after my last LKML'd patch (for cosmetic changes). These
> changes introduce configurable KERN_DEBUG level printk output for a
> variety of different things that the driver does and provides the
> framework for enhanced future debugging support as well.
>
> As always, comments welcome!
> + case BLKROSET: return "set-read-only";
> + case BLKROGET: return "get-read-only";
> + case BLKGETSIZE: return "block-get-size";
> + case BLKFLSBUF: return "flush-buffer-cache";
The last 4 never make it to the driver (nor should they, being generic
ioctls).
> + reply.magic = ntohl(reply.magic);
> + if (reply.magic != NBD_REPLY_MAGIC) {
> + printk(KERN_ERR "%s: Wrong magic (0x%lx)\n",
> + lo->disk->disk_name,
> + (unsigned long)reply.magic);
> + reply.error = ntohl(reply.error);
> + if (reply.error) {
> + printk(KERN_ERR "%s: Other side returned error (%d)\n",
> + lo->disk->disk_name, reply.error);
Generally a bad taste - it's harmless in this case, but such endianness
conversions in place are asking for trouble.
> lo->refcnt--;
> + dprintk(DBG_RELEASE, "%s: %s refcnt=%d\n", lo->disk->disk_name,
> + __FUNCTION__, lo->refcnt);
> /* N.B. Doesn't lo->file need an fput?? */
> return 0;
a) please, lose __FUNCTION__ - using it in macros is one thing, but
directly in a function that got a name shorter than `__FUNCTION__'?
b) no, it doesn't.
c) ->refcnt is never used. How about losing it completely? Along with
->open() and ->release()...
> sreq.flags = REQ_SPECIAL;
> nbd_cmd(&sreq) = NBD_CMD_DISC;
;-/
> + sreq.sector = 0;
> + sreq.nr_sectors = 0;
Umm... What for?
> if (sizeof(struct nbd_request) != 28) {
> - printk(KERN_CRIT "Sizeof nbd_request needs to be 28 in order to work!\n" );
> + printk(KERN_CRIT "nbd: Sizeof nbd_request needs to be 28 in order to work!\n" );
> return -EIO;
> }
FWIW, I'm less than sure that struct nbd_request is worth defining.
We use it in two places - the check above and nbd_send_req() where
it is filled and then its address is cast to char *. It might be
better to use u32[7] directly and forget about all alignment issues.
Hell knows... In this situation I would probably just define an
enum for offsets and be done with that. Same goes for nbd_reply.
next prev parent reply other threads:[~2003-06-24 2:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-24 2:04 Lou Langholtz
2003-06-24 2:59 ` viro [this message]
2003-06-24 4:09 ` Lou Langholtz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030624025959.GO6754@parcelfarce.linux.theplanet.co.uk \
--to=viro@parcelfarce.linux.theplanet.co.uk \
--cc=akpm@digeo.com \
--cc=ldl@aros.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®