On 2019/2/15 15:36, Dan Carpenter wrote:
> On Fri, Feb 15, 2019 at 10:10:34AM +0800, Chao Yu wrote:
>> Hi Dan,
>>
>> Any suggestion?
>>
>
> I won't NAK whatever you decide. But my opinion is that you should
> just use normal kernel memory allocators even though it means you have
> to use two diff
On Fri, Feb 15, 2019 at 10:10:34AM +0800, Chao Yu wrote:
> Hi Dan,
>
> Any suggestion?
>
I won't NAK whatever you decide. But my opinion is that you should
just use normal kernel memory allocators even though it means you have
to use two different fault injection frameworks.
Over time it would
Hi Dan,
Any suggestion?
On 2019/2/3 10:52, Chao Yu wrote:
> Sorry for the delay due to business travel.
>
> On 2019/1/29 2:30, Dan Carpenter wrote:
>> On Tue, Jan 29, 2019 at 12:41:55AM +0800, Chao Yu wrote:
>>> Hi Dan and Xiang,
>>>
>>> On 2019-1-28 21:48, Gao Xiang wrote:
Hi Dan,
>>>
Sorry for the delay due to business travel.
On 2019/1/29 2:30, Dan Carpenter wrote:
> On Tue, Jan 29, 2019 at 12:41:55AM +0800, Chao Yu wrote:
>> Hi Dan and Xiang,
>>
>> On 2019-1-28 21:48, Gao Xiang wrote:
>>> Hi Dan,
>>>
>>> On 2019/1/28 21:33, Dan Carpenter wrote:
Hopefully, regular kmallo
Hi,
On 2019/1/29 2:30, Dan Carpenter wrote:
> Are you serious? The standard fault injection doesn't do that???
>
> Please fix it instead of creating a duplicate better implementation
> which only your filesystem can use. I would have thought that obviously
> any fault injection framework could
On Tue, Jan 29, 2019 at 12:41:55AM +0800, Chao Yu wrote:
> Hi Dan and Xiang,
>
> On 2019-1-28 21:48, Gao Xiang wrote:
> > Hi Dan,
> >
> > On 2019/1/28 21:33, Dan Carpenter wrote:
> >> Hopefully, regular kmalloc() is enough.
> >>
> >> Do really need the erofs_kmalloc() function? Regular kmalloc()
Hi Dan and Xiang,
On 2019-1-28 21:48, Gao Xiang wrote:
> Hi Dan,
>
> On 2019/1/28 21:33, Dan Carpenter wrote:
>> Hopefully, regular kmalloc() is enough.
>>
>> Do really need the erofs_kmalloc() function? Regular kmalloc() has
>> fault injection already. Have you tried to use it?
Yes, I think w
On 2019/1/28 22:28, Dan Carpenter wrote:
> The point is, that people shouldn't recreate core code that already
> exists. At least try it out and have an explanation why the other code
> doesn't work.
>
> In other projects, the default is to keep code around once it has been
> written but in st
The point is, that people shouldn't recreate core code that already
exists. At least try it out and have an explanation why the other code
doesn't work.
In other projects, the default is to keep code around once it has been
written but in staging the default choice is to delete the code unless
th
Hi Dan,
On 2019/1/28 21:33, Dan Carpenter wrote:
> Hopefully, regular kmalloc() is enough.
>
> Do really need the erofs_kmalloc() function? Regular kmalloc() has
> fault injection already. Have you tried to use it?
The fault injection subsystem was introduced in the initial upstreamed
EROFS ve
On Sat, Jan 26, 2019 at 10:48:53AM +0800, Chao Yu wrote:
> On 2019/1/26 0:10, Gao Xiang wrote:
> > Let's add .get_acl() to read the file's acl from its xattrs
> > to make POSIX ACL usable.
> >
> > Here is the on-disk detail,
> > fullname: system.posix_acl_access
> > struct erofs_xattr_entry:
> >
Hi Chao,
On 2019/1/26 10:48, Chao Yu wrote:
> On 2019/1/26 0:10, Gao Xiang wrote:
>> Let's add .get_acl() to read the file's acl from its xattrs
>> to make POSIX ACL usable.
>>
>> Here is the on-disk detail,
>> fullname: system.posix_acl_access
>> struct erofs_xattr_entry:
>> .e_name_len =
On 2019/1/26 0:10, Gao Xiang wrote:
> Let's add .get_acl() to read the file's acl from its xattrs
> to make POSIX ACL usable.
>
> Here is the on-disk detail,
> fullname: system.posix_acl_access
> struct erofs_xattr_entry:
> .e_name_len = 0
> .e_name_index = EROFS_XATTR_INDEX_POSIX_
13 matches
Mail list logo
