<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-2">
</head>
<body>
<pre>
</pre>
<div class="moz-cite-prefix">
<pre>on 2019/11/21 16:32, Petr Vorel wrote:</pre>
</div>
<blockquote type="cite" cite="mid:20191121083215.GC14920@dell5510">
<pre class="moz-quote-pre" wrap="">Hi Xu,
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I see. Now, I think we should avoid to use <linux/types.h> because on musl libc doesn't have it.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">IMHO <linux/types.h> are always installed from kernel, not from libc
(packaged result of make headers_install run from kernel sources).</pre>
</blockquote>
<pre>Oh, you are right. For this case, using <linux/types.h> is right that we don't have situation such as fanotify . </pre>
<blockquote type="cite" cite="mid:20191121083215.GC14920@dell5510">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Also ,If we use uint64_t, they still failed on 2.6.32-754.el6.x86_64 with undefined . Or, we should use TST_ABI to define uint64_t them
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Hm, that what I said: using kernel headers is imho easier that using libc
headers (fewer problems with compatibility).
Anyway, I don't want to block this patchset.
We can always merge it as it is and sort/fix this problem later.</pre>
</blockquote>
<pre>Yes. kernel header is more eaiser that libc. Thanks.</pre>
<blockquote type="cite" cite="mid:20191121083215.GC14920@dell5510">
<pre class="moz-quote-pre" wrap="">
Kind regards,
Petr
</pre>
</blockquote>
</body>
</html>