From: Randy Dunlap <rdunlap@infradead.org>
To: Jayant Chowdhary <jchowdhary@google.com>,
LKML <linux-kernel@vger.kernel.org>
Cc: linux-kbuild <linux-kbuild@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
kernel-team@android.com
Subject: Re: uapi headers userspace build results
Date: Mon, 27 May 2019 15:12:05 -0700 [thread overview]
Message-ID: <becd3d01-509b-d470-df48-e5ef0e21ae2a@infradead.org> (raw)
In-Reply-To: <9b76d1b6-08a4-36cf-4fc8-661b216ca433@infradead.org>
Hi Jayant,
What ever happened to this script and subsequent patches?
thanks.
On 6/19/18 11:17 AM, Randy Dunlap wrote:
> On 06/18/2018 06:47 PM, Jayant Chowdhary wrote:
>> Hi Randy,
>>
>> On 06/12/2018 05:07 PM, Randy Dunlap wrote:
>>> On 06/12/2018 01:39 PM, Jayant Chowdhary wrote:
>>>> Hi Randy,
>>>>
>>>> On 06/11/2018 10:49 PM, Randy Dunlap wrote:
>>>>> Hi,
>>>>>
>>>>> Here is what I have so far. It begins with a makefile and some
>>>>> template files that are added to. There's a good bit of Perl also.
>>>>>
>>>>> I put all of these files in tools/uapi/ and run them from there.
>>>>>
>>>>> There is one .c file generated for each .h file in builddir/usr/include
>>>>> (O=builddir).
>>>>>
>>>>
>>>> Thanks for this! I wrote a small Makefile (uapi-compile.mk) which I'd put in
>>>> tools/build (I can change this to tools/uapi, if that is more apt).
>>>
>>> Your makefile foo is much better than mine is.
>>> Yes, I think that it deserves to be in its own sub-directory.
>>>
>>>> uapi-compile.mk straight-away compiles the uapi headers, without pulling them
>>>> into any generated c source files. It may also be invoked with an environment
>>>
>>> Hm, I didn't even know that is possible.
>>>
>>>> variable 'UAPI_DIR' specifying the directory, for which the user would like to
>>>> compile headers. This way we can test a directory at a time as well. In your
>>>
>>> Yes, good, I was planning to make a way to restrict the build to certain sub-dirs.
>>>
>>>> opinion, would this be simpler to have rather than having to auto-generate c
>>>> source files including each uapi header and also autog-enerating the make
>>>> targets? I feel like this approach would make maintaining these makefiles/
>>>> scripts easier as well.
>>>
>>> Sure, this is much better than my scripts.
>>>
>>>>> Out of 889 header files, I see 45 errors. That is better than I expected.
>>>>>
>>>>> The makefiles and scripts are attached (tar), as well as the output (I used
>>>>> 'make -ik' so that make would keep going after errors and attempt to build
>>>>> all target files).
>>>>>
>>>>> have fun!
>>>>>
>>>>
>>>> I did a 'make ARCH=arm64 headers_install' from the kernel source's root, and
>>>> then a 'make -kf uapi-compile.mk all > build.log 2>&1' to compile all the
>>>> headers. Out of 864 headers, I see 20 compilation failures.
>>>>
>>>> I'm attaching uapi-compile.mk and the build.log file along.
>>>
>>> I have some usage comments.
>>>
>>> Since I ran 'make ARCH=x86_64 O=xx64 headers_install', I had to modify
>>> uapi-compile.mk to use that SRC_DIR:
>>>
>>> SRC_DIR :=../../xx64
>>>
>>> Also, I first tried to make BDIR as a sub-directory of tools/uapi/ and
>>> uapi-compile.mk did not work (when using BDIR=BDIR).
>>> Then I did 'mkdir ../../xx64/BDIR' and specified BDIR=../../xx64/BDIR and
>>> that worked. But: that sub-dir is not used:
>>>
>>> gcc -I../../xx64/usr/include/ --include=../../xx64/usr/include/linux/posix_types.h --include=../../xx64/usr/include/asm-generic/ipcbuf.h --include=stdarg.h --include=stdint.h --include=stddef.h -c ../../xx64/usr/include//linux/caif/caif_socket.h -o ../../xx64/BDIR/../../xx64/usr/include//linux/caif/caif_socket.o
>>> [see the next comment]
>>>
>>> Oh, this makefile builds the .o files in the same sub-dirs as their
>>> respective .h files. I don't especially like that, but as long as
>>> make clean works, it will do. [and make clean does work]
>>>
>>
>> Thanks for these comments. I'll take care of them in my patch-set. I've got a
>> couple of questions for you. Since most of the errors were found in the
>> include/uapi/linux directory, I tried investigating why.
>
> Please also repost your latest patch-set.
>
>> 1) I found that multiple headers depend on the definition of types such as
>> pid_t, which have no definition in the set of uapi headers. There is a
>> definition (of pid_t) in include/linux/types.h, and I thought we could try
>> exposing that in the set of uapi headers. One problem I can see with that is
>> that the header has some definitions which depend on kernel configs: eg:
>> CONFIG_ARCH_DMA_ADDR_T_64BIT. Since user-land programs shouldn't really assume
>> kernel configs, I was thinking we should re-factor this header so that
>> appropriate parts can be exposed to user-land.
>
> Sure, that's worth a try. Mostly on a case-by-case basis.
>
> I see that (at least in the distro that I am using)
> /usr/include/asm-generic/posix_types.h has a typedef for __kernel_pid_t.
> I wonder if that could be co-opted, but I expect that this would have
> type/size issues.
>
> OTOH, 'man getpid' uses pid_t and refers to <sys/types.h> and <unistd.h>,
> so there should already be a pid_t for userspace. Just #include more
> headers files. :)
>
>> 2) Some headers try to expose information which should probably not be exposed
>> to user-land. eg: wait_queue_head in linux/coda_psdev.h (this header should
>> probably be removed altogether ?)
>
> I suppose that header file describes a kernel-to-userspace ("Venus") interface,
> so maybe not removed altogether. But the wait_queue_head_t part of it should
> just be some padding/reserved field (of what size/type?).
>
>
>> Do you have better ideas ?
>
> slow and steady.
>
--
~Randy
next prev parent reply other threads:[~2019-05-27 22:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-12 5:49 uapi headers userspace build results Randy Dunlap
2018-06-12 20:39 ` Jayant Chowdhary
2018-06-13 0:07 ` Randy Dunlap
2018-06-19 1:47 ` Jayant Chowdhary
2018-06-19 18:17 ` Randy Dunlap
2019-05-27 22:12 ` Randy Dunlap [this message]
2019-05-28 17:06 ` Jayant Chowdhary
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=becd3d01-509b-d470-df48-e5ef0e21ae2a@infradead.org \
--to=rdunlap@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=jchowdhary@google.com \
--cc=kernel-team@android.com \
--cc=linux-kbuild@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).