On Thursday 24 September 2009, Stefan Seyfried wrote: > On Thu, 24 Sep 2009 00:28:03 +0200 > "Rafael J. Wysocki" <rjw@xxxxxxx> wrote: > > > On Wednesday 23 September 2009, Rodolfo (kix) wrote: > > > Hi Rafael, > > > > Hi, > > > > > I am thinking about the maintaining ... > > Good luck! I know that you'll need it ;) > > Let me throw my 2 cents into the bowl. > > > > 1. The users sends the hardware info to be added to the database > > > (now by mail). Then: > > > > > > 1. Probably we need a little script (or web script? or post directly > > > form the s2ram -i?): > > > 1.a The script checks if the machine is previously added to the > > > database (in a text file). Probably this script can read from the > > > mailing list format > > > > > > xxxx:% sudo /root/s2ram -i > > > This machine can be identified by: > > > sys_vendor = "TOSHIBA" > > > sys_product = "Satellite U305" > > > sys_version = "PSU34U-00L003" > > > bios_version = "V1.70 " > > > See http://en.opensuse.org/S2ram for details. > > > > > > 1.b If is not added, the script add the machine to a text file. > > > > However you arrange that is up to you. My experience is that the > > users generally send whitelist information by email. > > > > > 2. The text file can be processed using a little script to convert > > > it to the "whitelist.[c,h]" files and converted to web page > > > (s2whitelist and s2web :-)) > > > 3. The script can do a git update if needed. > > > > Well, I'm surely not going to allow the script to update the master > > git tree at kernel.org directly. > > There's also the issue that some sanity checking should be done before > adding an entry. Pretty often, users send some hilarious option > combinations, on machines that should nowadays just work without any > options (e.g. intel-based). Agreed. > The next thing is, that I, personally, would reject any machines that > should work out of the box nowadays with in-kernel drivers (means: > intel, nvidia- and ATI binary-module driven). You can only make things > worse on such machines with userspace workarounds, and they should be > recognized automatically by recent (means: newer than 2 years) > pm-utils, so that no hack is needed. IMHO the whitelist should not be > cluttered with them. Agreed in general, maybe except for the binary driver part. I certainly prefer people using s2ram's workarounds to people installing binary graphics drivers just to make suspend work. > > > In my opinion, the file should have this format: > > > > > > <author info for the comment's > > > line>·<sys_vendor>·<sys_product>·<sys_version>·<bios_version>·<flags> > > > > > > I am using the "·" separator because probably is not used in any > > > field. > > > > What's the code of this character? > > Something strange ;-) > > I'd use the pipe character: '|'. I have not yet encountered it in > s2ram-relevant DMI data. It still is readable and not subject to > encoding issues AFAICT. Yes, it is an ASCII character (officially called "vertical bar" BTW). > I'd put the author info / comment at the end, since then you can > sort/grep for sys_vendor easily, which is probably most useful. Agreed. > And I still think that nowadays s2ram is the wrong tool for the > whitelist, but well... :-) Oh, you know my opinion. ;-) Still, if Rodolfo is willing to maintain the whitelist, I won't object. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
