rich...@nod.at writes:
> Am 01.11.2013 20:22, schrieb Seiji Aguchi:
>>>
>>> Agreed. I liked your ((timestamp * 100 + part) * 100 + count function much
>>> more than this.
>>
>> I was worried that the part and count could be more than 100.
>> If it happens, the id may not be unique...
>>
>>
rich...@nod.at writes:
Am 01.11.2013 20:22, schrieb Seiji Aguchi:
Agreed. I liked your ((timestamp * 100 + part) * 100 + count function much
more than this.
I was worried that the part and count could be more than 100.
If it happens, the id may not be unique...
But, currently, size
> How does efivars backend handle "unlink(2)" in the pstore file system.
> pstore will call the backend->erase function passing the "id". The
> backend should then erase the right record from persistent storage.
>
> With the ((timestamp * 100 + part) * 100 + count function - you can
> easily
How does efivars backend handle unlink(2) in the pstore file system.
pstore will call the backend-erase function passing the id. The
backend should then erase the right record from persistent storage.
With the ((timestamp * 100 + part) * 100 + count function - you can
easily reverse it to
rich...@nod.at writes:
> Am 01.11.2013 20:22, schrieb Seiji Aguchi:
> +{
> + char id_str[64];
> + u64 id = 0;
> +
> + sprintf(id_str, "%lu%u%d", timestamp, part, count);
> + if (kstrtoull(id_str, 10, ))
> + pr_warn("efi-pstore:
On Fri, Nov 1, 2013 at 1:57 PM, Seiji Aguchi wrote:
>> What about feeding the bytes of all three integers into a non-cryptographic
>> hash function?
>> Using this way you get a cheap unique id.
>
> It is reasonable to me.
How does efivars backend handle "unlink(2)" in the pstore file system.
> What about feeding the bytes of all three integers into a non-cryptographic
> hash function?
> Using this way you get a cheap unique id.
It is reasonable to me.
Seiji
Am 01.11.2013 20:22, schrieb Seiji Aguchi:
+{
+ char id_str[64];
+ u64 id = 0;
+
+ sprintf(id_str, "%lu%u%d", timestamp, part, count);
+ if (kstrtoull(id_str, 10, ))
+ pr_warn("efi-pstore: failed to generate id\n");
+
> >> +{
> >> + char id_str[64];
> >> + u64 id = 0;
> >> +
> >> + sprintf(id_str, "%lu%u%d", timestamp, part, count);
> >> + if (kstrtoull(id_str, 10, ))
> >> + pr_warn("efi-pstore: failed to generate id\n");
> >> + return id;
> >> +}
> >
> > This is just
>> +static u64 efi_generate_id(unsigned long timestamp, unsigned int part, int
>> count)
I don't think the "efi_" prefix is needed here. For one thing the
function is static, so
no name space pollution worries. For another - it makes it look like
this is some thing
defined in EFI standard. If
On Fri, Nov 1, 2013 at 5:14 PM, Madper Xie wrote:
>
> Pstore fs expects that backends provide a uniqued id which could avoid
> pstore making entries as duplication or denominating entries the same
> name. So I combine the timestamp, part and count into id.
>
> Signed-off-by: Madper Xie
> ---
>
Pstore fs expects that backends provide a uniqued id which could avoid
pstore making entries as duplication or denominating entries the same
name. So I combine the timestamp, part and count into id.
Signed-off-by: Madper Xie
---
drivers/firmware/efi/efi-pstore.c | 22 ++
1
Pstore fs expects that backends provide a uniqued id which could avoid
pstore making entries as duplication or denominating entries the same
name. So I combine the timestamp, part and count into id.
Signed-off-by: Madper Xie c...@redhat.com
---
drivers/firmware/efi/efi-pstore.c | 22
On Fri, Nov 1, 2013 at 5:14 PM, Madper Xie c...@redhat.com wrote:
Pstore fs expects that backends provide a uniqued id which could avoid
pstore making entries as duplication or denominating entries the same
name. So I combine the timestamp, part and count into id.
Signed-off-by: Madper Xie
+static u64 efi_generate_id(unsigned long timestamp, unsigned int part, int
count)
I don't think the efi_ prefix is needed here. For one thing the
function is static, so
no name space pollution worries. For another - it makes it look like
this is some thing
defined in EFI standard. If
+{
+ char id_str[64];
+ u64 id = 0;
+
+ sprintf(id_str, %lu%u%d, timestamp, part, count);
+ if (kstrtoull(id_str, 10, id))
+ pr_warn(efi-pstore: failed to generate id\n);
+ return id;
+}
This is just odd. You make a string from
Am 01.11.2013 20:22, schrieb Seiji Aguchi:
+{
+ char id_str[64];
+ u64 id = 0;
+
+ sprintf(id_str, %lu%u%d, timestamp, part, count);
+ if (kstrtoull(id_str, 10, id))
+ pr_warn(efi-pstore: failed to generate id\n);
+ return id;
+}
This is just
What about feeding the bytes of all three integers into a non-cryptographic
hash function?
Using this way you get a cheap unique id.
It is reasonable to me.
Seiji
On Fri, Nov 1, 2013 at 1:57 PM, Seiji Aguchi seiji.agu...@hds.com wrote:
What about feeding the bytes of all three integers into a non-cryptographic
hash function?
Using this way you get a cheap unique id.
It is reasonable to me.
How does efivars backend handle unlink(2) in the pstore file
rich...@nod.at writes:
Am 01.11.2013 20:22, schrieb Seiji Aguchi:
+{
+ char id_str[64];
+ u64 id = 0;
+
+ sprintf(id_str, %lu%u%d, timestamp, part, count);
+ if (kstrtoull(id_str, 10, id))
+ pr_warn(efi-pstore: failed to generate id\n);
+
20 matches
Mail list logo
