From: JeffleXu <jefflexu@linux.alibaba.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: dhowells@redhat.com, linux-cachefs@redhat.com, xiang@kernel.org,
chao@kernel.org, linux-erofs@lists.ozlabs.org,
torvalds@linux-foundation.org, willy@infradead.org,
linux-fsdevel@vger.kernel.org, joseph.qi@linux.alibaba.com,
bo.liu@linux.alibaba.com, tao.peng@linux.alibaba.com,
gerry@linux.alibaba.com, eguan@linux.alibaba.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 05/23] cachefiles: introduce new devnode for on-demand read mode
Date: Thu, 17 Feb 2022 09:49:26 +0800 [thread overview]
Message-ID: <a3da9289-665d-ea37-5ab9-b97b883f694f@linux.alibaba.com> (raw)
In-Reply-To: <Yg0421B10PPwunI+@kroah.com>
On 2/17/22 1:48 AM, Greg KH wrote:
> On Wed, Feb 16, 2022 at 08:49:35PM +0800, JeffleXu wrote:
>>>> +struct cachefiles_req_in {
>>>> + uint64_t id;
>>>> + uint64_t off;
>>>> + uint64_t len;
>>>
>>> For structures that cross the user/kernel boundry, you have to use the
>>> correct types. For this it would be __u64.
>>
>> OK I will change to __xx style in the next version.
>>
>> By the way, I can't understand the disadvantage of uintxx_t style.
>
> The "uint*" types are not valid kernel types. They are userspace types
> and do not transfer properly in all arches and situations when crossing
> the user/kernel boundry. They are also in a different C "namespace", so
> should not even be used in kernel code, although a lot of people do
> because they are used to writing userspace C code :(
OK. "uint*" types are defined in ISO C library, while it seems that
linux kernel doesn't expect any C library [1].
[1] https://kernelnewbies.org/FAQ/LibraryFunctionsInKernel
Thanks for explaining it.
--
Thanks,
Jeffle
next prev parent reply other threads:[~2022-02-17 1:49 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-09 6:00 [PATCH v3 00/22] fscache,erofs: fscache-based demand-read semantics Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 01/22] fscache: export fscache_end_operation() Jeffle Xu
2022-02-17 7:44 ` Liu Bo
2022-02-09 6:00 ` [PATCH v3 02/22] fscache: add a method to support on-demand read semantics Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 03/22] cachefiles: extract generic function for daemon methods Jeffle Xu
2022-02-17 8:17 ` Liu Bo
2022-02-09 6:00 ` [PATCH v3 04/22] cachefiles: detect backing file size in on-demand read mode Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 05/22] cachefiles: introduce new devnode for " Jeffle Xu
2022-02-15 9:03 ` JeffleXu
2022-02-15 10:37 ` Greg KH
2022-02-16 8:17 ` JeffleXu
2022-02-15 11:13 ` [PATCH v4 05/23] " Jeffle Xu
2022-02-16 10:48 ` Greg KH
2022-02-16 12:49 ` JeffleXu
2022-02-16 17:48 ` Greg KH
2022-02-17 1:49 ` JeffleXu [this message]
2022-02-09 6:00 ` [PATCH v3 06/22] erofs: use meta buffers for erofs_read_superblock() Jeffle Xu
2022-02-09 7:52 ` Gao Xiang
2022-02-09 6:00 ` [PATCH v3 07/22] erofs: export erofs_map_blocks() Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 08/22] erofs: add mode checking helper Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 09/22] erofs: register global fscache volume Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 10/22] erofs: add cookie context helper functions Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 11/22] erofs: add anonymous inode managing page cache of blob file Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 12/22] erofs: add erofs_fscache_read_page() helper Jeffle Xu
2022-02-09 6:00 ` [PATCH v3 13/22] erofs: register cookie context for bootstrap blob Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 14/22] erofs: implement fscache-based metadata read Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 15/22] erofs: implement fscache-based data read for non-inline layout Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 16/22] erofs: implement fscache-based data read for inline layout Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 17/22] erofs: register cookie context for data blobs Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 18/22] erofs: implement fscache-based data read " Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 19/22] erofs: implement fscache-based data readahead for hole Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 20/22] erofs: implement fscache-based data readahead for non-inline layout Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 21/22] erofs: implement fscache-based data readahead for inline layout Jeffle Xu
2022-02-09 6:01 ` [PATCH v3 22/22] erofs: add 'uuid' mount option Jeffle Xu
2022-02-10 5:58 ` [Linux-cachefs] [PATCH v3 00/22] fscache, erofs: fscache-based demand-read semantics Gao Xiang
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=a3da9289-665d-ea37-5ab9-b97b883f694f@linux.alibaba.com \
--to=jefflexu@linux.alibaba.com \
--cc=bo.liu@linux.alibaba.com \
--cc=chao@kernel.org \
--cc=dhowells@redhat.com \
--cc=eguan@linux.alibaba.com \
--cc=gerry@linux.alibaba.com \
--cc=gregkh@linuxfoundation.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-cachefs@redhat.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tao.peng@linux.alibaba.com \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.org \
--cc=xiang@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).