From: "Jan Beulich" <JBeulich@suse.com>
To: "Don Zickus" <dzickus@redhat.com>
Cc: <mmarek@suse.cz>, "LKML" <linux-kernel@vger.kernel.org>
Subject: Re: genksyms: separating public headers from private header files
Date: Wed, 23 Jul 2014 09:28:32 +0100 [thread overview]
Message-ID: <53CF8E500200007800024FD1@mail.emea.novell.com> (raw)
In-Reply-To: <20140716151915.GS7959@redhat.com>
>>> On 16.07.14 at 17:19, <dzickus@redhat.com> wrote:
> Hi Jan, Michal,
>
> I am not sure who maintains genksyms officially, so I am sending this
> question to the two of you as folks who seemed to have contributed to the
> tool. :-)
>
> I noticed with genksyms that a symbol is opaquely defined in a
> public header file (on purpose) and then fully defined in a private
> header. This is normal practice. Further, symbol checksumming is done on
> EXPORT_SYMBOLs in a private c file that includes the private header
> files.
>
> As a result, even though a struct symbol is intentionally opaquely defined
> in a public header file consumed by a third party module, the symbol
> checksumming still includes the full definition (because the private c
> file with the actual export symbol has the full definition). This has
> made it difficult to modify the private header file struct because it
> breaks the symbol checksumming.
>
> For example, let's consider
>
> block/blk-core.c:EXPORT_SYMBOL(blk_put_queue);
>
> blk_put_queue will eventually depend on struct blkcq_gq.
>
> Now publicly blkcg_gq is defined opaquely in
>
> include/linux/blkdev.h
>
> and privately in
>
> block/block-cgroup.h
>
> Now when we checksum blk_put_queue both include/linux/blkdev.h and
> block/block-cgroup.h are included in block/blk-core.c, so blkcg_gq is
> fully defined for checksumming.
>
> Later if we modify blkcq_gq in block/block-cgroup.h the checksum changes,
> even though it can debated that block-cgroup.h is a private header file
> and it should not impact kabi for third party modules.
>
> Have either of you run into this? Or is the argument that private files
> should not impact the checksum not as strong as I might think? Or is it a
> technical problem of how to separate the public includes from the private
> includes in the preprocessed file?
Yes, I think we've run into this (if not elsewhere then by seeing [and
having to wave] false positive kABI changes). Besides being a
technical problem of separating one kind of header from the other, I'm
also unsure whether uniformly ignoring definitions in private headers
would always be correct. Hence I think a possible solution to this ought
to involve manual annotation of structures not to participate in CRC
calculations.
Jan
next prev parent reply other threads:[~2014-07-23 8:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 15:19 genksyms: separating public headers from private header files Don Zickus
2014-07-23 8:28 ` Jan Beulich [this message]
2014-07-23 13:52 ` Don Zickus
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=53CF8E500200007800024FD1@mail.emea.novell.com \
--to=jbeulich@suse.com \
--cc=dzickus@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.cz \
/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;
as well as URLs for NNTP newsgroup(s).