All of lore.kernel.org
 help / color / mirror / Atom feed
From: Madper Xie <cxie-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org>
Cc: "Seiji Aguchi" <seiji.aguchi-7rDLJAbr9SE@public.gmane.org>,
	"Tony Luck" <tony.luck-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Madper Xie" <cxie-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"matt.fleming@intel.com"
	<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	linux-kernel
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Linux EFI" <linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	谢成骏 <bbboson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH] Make efi-pstore return a unique id
Date: Wed, 20 Nov 2013 17:29:12 +0800	[thread overview]
Message-ID: <87r4abmnfb.fsf@redhat.com> (raw)
In-Reply-To: <52740A3A.70202-/L3Ra7n9ekc@public.gmane.org>


richard-/L3Ra7n9ekc@public.gmane.org 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 of nvram storage is limited, so it is a corner case.
>> I respect your opinion.
>
> What about feeding the bytes of all three integers into a
> non-cryptographic hash function?

Then will lost the sequence of our log. We will get lots of entries like
"dmesg-efi-`unique but meaningless number here`" in pstore fs. Who will
know which file is the latest record?
A possible way is sort them by created time. But pstore splits large
messages into many parts. So they will have the same created-time. Like
the following case:
[root@dhcp-13-41 ~]# ls -rtl /dev/pstore/
total 0
-r--r--r--. 1 root root  930 Nov 15 08:42 dmesg-efi-9
-r--r--r--. 1 root root 1017 Nov 15 08:42 dmesg-efi-8
-r--r--r--. 1 root root  993 Nov 15 08:42 dmesg-efi-7
-r--r--r--. 1 root root  984 Nov 15 08:42 dmesg-efi-6
-r--r--r--. 1 root root 1008 Nov 15 08:42 dmesg-efi-5
-r--r--r--. 1 root root  909 Nov 15 08:42 dmesg-efi-10
-r--r--r--. 1 root root 1003 Nov 15 08:42 dmesg-efi-11
-r--r--r--. 1 root root  980 Nov 18 00:41 dmesg-efi-4
-r--r--r--. 1 root root  990 Nov 18 00:41 dmesg-efi-3
-r--r--r--. 1 root root  966 Nov 18 00:41 dmesg-efi-2
-r--r--r--. 1 root root 1010 Nov 18 00:41 dmesg-efi-1

or more intuitive:
ls /sys/firmware/efi/efivars/ | grep -i "dump" | cut -d'-' -f5 | sort |wc -l
103
ls /sys/firmware/efi/efivars/ | grep -i "dump" | cut -d'-' -f5 | sort |uniq |wc -l
26

So if we using a hashed unique number for uniqueness, we will lose the
sequence. We must sort them manually.

And another side, the combin of timestamp, count and part is unique. Why
we generate a unique number from a unique number?
if you think "making a string from three ints and then a parse it to a
int again" is odd, i'd like to use ((timestamp * 100 + part) * 100 +
count.

> Using this way you get a cheap unique id.
>
> Thanks,
> //richard

WARNING: multiple messages have this Message-ID (diff)
From: Madper Xie <cxie@redhat.com>
To: Richard Weinberger <richard@nod.at>
Cc: "Seiji Aguchi" <seiji.aguchi@hds.com>,
	"Tony Luck" <tony.luck@gmail.com>, "Madper Xie" <cxie@redhat.com>,
	"matt.fleming@intel.com" <matt.fleming@intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"Linux EFI" <linux-efi@vger.kernel.org>, 谢成骏 <bbboson@gmail.com>
Subject: Re: [PATCH] Make efi-pstore return a unique id
Date: Wed, 20 Nov 2013 17:29:12 +0800	[thread overview]
Message-ID: <87r4abmnfb.fsf@redhat.com> (raw)
In-Reply-To: <52740A3A.70202@nod.at>


richard@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 of nvram storage is limited, so it is a corner case.
>> I respect your opinion.
>
> What about feeding the bytes of all three integers into a
> non-cryptographic hash function?

Then will lost the sequence of our log. We will get lots of entries like
"dmesg-efi-`unique but meaningless number here`" in pstore fs. Who will
know which file is the latest record?
A possible way is sort them by created time. But pstore splits large
messages into many parts. So they will have the same created-time. Like
the following case:
[root@dhcp-13-41 ~]# ls -rtl /dev/pstore/
total 0
-r--r--r--. 1 root root  930 Nov 15 08:42 dmesg-efi-9
-r--r--r--. 1 root root 1017 Nov 15 08:42 dmesg-efi-8
-r--r--r--. 1 root root  993 Nov 15 08:42 dmesg-efi-7
-r--r--r--. 1 root root  984 Nov 15 08:42 dmesg-efi-6
-r--r--r--. 1 root root 1008 Nov 15 08:42 dmesg-efi-5
-r--r--r--. 1 root root  909 Nov 15 08:42 dmesg-efi-10
-r--r--r--. 1 root root 1003 Nov 15 08:42 dmesg-efi-11
-r--r--r--. 1 root root  980 Nov 18 00:41 dmesg-efi-4
-r--r--r--. 1 root root  990 Nov 18 00:41 dmesg-efi-3
-r--r--r--. 1 root root  966 Nov 18 00:41 dmesg-efi-2
-r--r--r--. 1 root root 1010 Nov 18 00:41 dmesg-efi-1

or more intuitive:
ls /sys/firmware/efi/efivars/ | grep -i "dump" | cut -d'-' -f5 | sort |wc -l
103
ls /sys/firmware/efi/efivars/ | grep -i "dump" | cut -d'-' -f5 | sort |uniq |wc -l
26

So if we using a hashed unique number for uniqueness, we will lose the
sequence. We must sort them manually.

And another side, the combin of timestamp, count and part is unique. Why
we generate a unique number from a unique number?
if you think "making a string from three ints and then a parse it to a
int again" is odd, i'd like to use ((timestamp * 100 + part) * 100 +
count.

> Using this way you get a cheap unique id.
>
> Thanks,
> //richard


  parent reply	other threads:[~2013-11-20  9:29 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01 16:14 [PATCH] Make efi-pstore return a unique id Madper Xie
2013-11-01 16:14 ` Madper Xie
     [not found] ` <87ppqk6qvx.fsf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-01 16:28   ` Richard Weinberger
2013-11-01 16:28     ` Richard Weinberger
     [not found]     ` <CAFLxGvz3pCevxE43zGnrbX4MxPmwyb=9MVNpzFRpELt1+AmtrA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-01 18:58       ` Tony Luck
2013-11-01 18:58         ` Tony Luck
     [not found]         ` <CA+8MBbJefz7L-C-LnhAAXB5zf-8XoMPhESPU4yd0wnuZ_YqO1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-01 19:22           ` Seiji Aguchi
2013-11-01 19:22             ` Seiji Aguchi
     [not found]             ` <A5ED84D3BB3A384992CBB9C77DEDA4D47F9DD941-ohthHghroY0jroPwUH3sq+6wyyQG6/Uh@public.gmane.org>
2013-11-01 20:08               ` Richard Weinberger
2013-11-01 20:08                 ` Richard Weinberger
2013-11-02  1:15                 ` Madper Xie
     [not found]                 ` <52740A3A.70202-/L3Ra7n9ekc@public.gmane.org>
2013-11-01 20:57                   ` Seiji Aguchi
2013-11-01 20:57                     ` Seiji Aguchi
     [not found]                     ` <A5ED84D3BB3A384992CBB9C77DEDA4D47F9DDA4D-ohthHghroY0jroPwUH3sq+6wyyQG6/Uh@public.gmane.org>
2013-11-02  0:17                       ` Tony Luck
2013-11-02  0:17                         ` Tony Luck
     [not found]                         ` <CA+8MBbKMRw28Ubr5F8U=5SKuaeutR+KEVDgJC70Xebj4O5BzpA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-02 12:28                           ` Seiji Aguchi
2013-11-02 12:28                             ` Seiji Aguchi
2013-11-20  9:29                   ` Madper Xie [this message]
2013-11-20  9:29                     ` Madper Xie
     [not found]                     ` <87r4abmnfb.fsf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-20 15:17                       ` Seiji Aguchi
2013-11-20 15:17                         ` Seiji Aguchi
     [not found]                         ` <A5ED84D3BB3A384992CBB9C77DEDA4D47FA0B6EF-ohthHghroY0jroPwUH3sq+6wyyQG6/Uh@public.gmane.org>
2013-11-21 13:53                           ` Madper Xie
2013-11-21 13:53                             ` Madper Xie

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=87r4abmnfb.fsf@redhat.com \
    --to=cxie-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=bbboson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=richard-/L3Ra7n9ekc@public.gmane.org \
    --cc=seiji.aguchi-7rDLJAbr9SE@public.gmane.org \
    --cc=tony.luck-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.