From: James Smart <James.Smart@Emulex.Com>
To: Mike Anderson <andmike@us.ibm.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] SCSI and FC Transport: add netlink support for posting of transport events
Date: Fri, 11 Aug 2006 10:23:40 -0400 [thread overview]
Message-ID: <44DC92EC.1020609@emulex.com> (raw)
In-Reply-To: <20060811043237.GA29551@us.ibm.com>
Mike Anderson wrote:
> What about using netlink attributes? The attributes do have more overhead,
> but it would seem that using attributes instead of sending out a
> whole structure would make it easier on the user space side to support
> different kernel versions without syncing the tools with the kernel.
Yeah, I guessed you were going to raise this.
I just didn't see any advantage to it. The macros really didn't help with
anything really interesting, such as endianness. I guess they do help with
some potential structure packing issues. I saw them as just ensuring that
you walked on the path right - which for most intents and purposes, you
will as you really are not self-discovering data. As long as you use
well-defined types and watch the structure alignments, it should be fine.
The overhead didn't seem worthit. Enlighten me if I'm taking them too lightly.
I'm assuming your "syncing the tools with the kernel" statement infers the
use of a version element in place of the attributes above. I don't see how
you lose the version. It's the key for the later structure decode regardless
of whether it's attribute-ized or not. Am I missing something ? I'm also
(obviously) a proponent of the version so that a tool can provide backward
compatibility, or spot new un-recognized data.
-- james
next prev parent reply other threads:[~2006-08-11 14:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-08 20:53 [PATCH] SCSI and FC Transport: add netlink support for posting of transport events James Smart
2006-08-11 4:32 ` Mike Anderson
2006-08-11 14:23 ` James Smart [this message]
2006-08-14 16:18 ` Mike Anderson
2006-08-14 18:40 ` James Smart
2006-08-17 19:56 ` James Smart
2006-08-17 21:24 ` Mike Anderson
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=44DC92EC.1020609@emulex.com \
--to=james.smart@emulex.com \
--cc=andmike@us.ibm.com \
--cc=linux-scsi@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.