Ok, I will write some lines to manage the whitelist. I will use your comments :-) Thanks! El 24/09/2009, a las 19:53, "Rafael J. Wysocki" <rjw@xxxxxxx> escribió: > 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
