Re: new Linux/ACPI home page

2007-10-28 Thread Pavel Machek
Hi!

  yes, acpidump would be more useful than just the DSDT --
  as we get all kinds of issues with all the tables.
  
  One problem is that shipping around BIOS images, particularly
  modified ones, is sort of a touchy area.  This is the code
  of the manufacturer, who may or may not be happy that the
  community is hacking their code.  If any of those manufactureres
  got mad at Intel for mucking with their BIOS code,
  that would be a bad day for we Intel employees.
  
  lesswatts.org is hosted by Intel.  So we'd need to
  sort though this issue before adding an acpidump database.
 
 Well, we have suspend.sf.net and the acpidump database can safely be put in
 there, I think. ;-)

Agreed.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


new Linux/ACPI home page

2007-10-25 Thread Len Brown
The home page for the Linux/ACPI project is moving here:

http://www.lesswatts.org/projects/acpi/

(Thank you to the lesswatts project for supplying webmaster
 and hosting resources for us:-)

I conjured up most of the content -- so please send
any feedback on content to me.

Don't sweat the formatting issues right now - the ink
is only a few hours old at this point and the webmaster
is actively fixing the obvious formatting glitches.

I've marked a couple of sections as TBD b/c I havn't
written them yet.  If you want to volunteer to help,
please let me know.

Re: http://acpi.sourceforge.net/

When the lesswatts page is solid, I'd like to
delete duplicate/stale content from sf -- as two
copies of the truth always leads to trouble,
and much of the sf content is stale now anyway.
However, I'd like to leave two things on sf.net
that will not be moving to lesswatts -- the documentation
of the /proc/acpi/ interfaces (which are becoming legacy
and going away), and the DSDT databse -- which I believe
is also somewhat of a historical artifact.

thanks,
-Len

-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: new Linux/ACPI home page

2007-10-25 Thread Alexey Starikovskiy
Len Brown wrote:
 and going away), and the DSDT databse -- which I believe
 is also somewhat of a historical artifact.
DSDT database or better acpidump.out database might be very useful,
if could be searched for particular feature -- absence of EC, use of SBS, etc.

Alex.
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: new Linux/ACPI home page

2007-10-25 Thread Len Brown
On Thursday 25 October 2007 15:24, Alexey Starikovskiy wrote:
 Len Brown wrote:

  and going away), and the DSDT databse -- which I believe
  is also somewhat of a historical artifact.

 DSDT database or better acpidump.out database might be very useful,
 if could be searched for particular feature -- absence of EC, use of SBS, etc.

True.

I don't like the original DSDT database -- it was from an era
when people thought that it was a good idea to hack a DSDT
to workaround Linux failures and share the hacked DSDT
with others.  That was a bad strategy and it should be abandoned.
DSDT hacking is for Linux debugging only -- Linux should
always be made to work with an un-modified DSDT.

yes, acpidump would be more useful than just the DSDT --
as we get all kinds of issues with all the tables.

One problem is that shipping around BIOS images, particularly
modified ones, is sort of a touchy area.  This is the code
of the manufacturer, who may or may not be happy that the
community is hacking their code.  If any of those manufactureres
got mad at Intel for mucking with their BIOS code,
that would be a bad day for we Intel employees.

lesswatts.org is hosted by Intel.  So we'd need to
sort though this issue before adding an acpidump database.

thanks,
-Len
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: new Linux/ACPI home page

2007-10-25 Thread Peter Clifton

On Thu, 2007-10-25 at 16:29 -0400, Len Brown wrote:
 On Thursday 25 October 2007 15:24, Alexey Starikovskiy wrote:
  Len Brown wrote:
 
   and going away), and the DSDT databse -- which I believe
   is also somewhat of a historical artifact.
 
  DSDT database or better acpidump.out database might be very useful,
  if could be searched for particular feature -- absence of EC, use of SBS, 
  etc.
 
 True.
 
 I don't like the original DSDT database -- it was from an era
 when people thought that it was a good idea to hack a DSDT
 to workaround Linux failures and share the hacked DSDT
 with others.  That was a bad strategy and it should be abandoned.
 DSDT hacking is for Linux debugging only -- Linux should
 always be made to work with an un-modified DSDT.

What about plain _crap_ DSDT's like some (mine at least) from HP where
there are problems which just can't be fixed without bypassing the DSDT
functionality (e.g. lid switches, video extension) and writing a driver
specific to that machine's chipset?

Even then, some of the issues are in SMI, so can't be fixed, but at
least with a hacked DSDT, I can get things mostly working with the new
user space. A BIOS would be the _right_ solution, but as the machine is
old, that isn't going to happen.

 yes, acpidump would be more useful than just the DSDT --
 as we get all kinds of issues with all the tables.
 
 One problem is that shipping around BIOS images, particularly
 modified ones, is sort of a touchy area.  This is the code
 of the manufacturer, who may or may not be happy that the
 community is hacking their code.  If any of those manufactureres
 got mad at Intel for mucking with their BIOS code,
 that would be a bad day for we Intel employees.

Aren't most of the BIOS codes based on reference implementations from
chipset vendors anyway? If so, I think Intel take the lead here and make
their reference BIOS code available publicly. It could be debugged by
the community at large, and perhaps we'd end up with derivative works
(OEM BIOS) of better quality.

Climbing down from the soap box now.

Best wishes

Peter

(who'd reverse engineer and patch his HP BIOS if only he had the
assembler-fu to do so).

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)

-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: new Linux/ACPI home page

2007-10-25 Thread Rafael J. Wysocki
On Thursday, 25 October 2007 22:29, Len Brown wrote:
 On Thursday 25 October 2007 15:24, Alexey Starikovskiy wrote:
  Len Brown wrote:
 
   and going away), and the DSDT databse -- which I believe
   is also somewhat of a historical artifact.
 
  DSDT database or better acpidump.out database might be very useful,
  if could be searched for particular feature -- absence of EC, use of SBS, 
  etc.
 
 True.
 
 I don't like the original DSDT database -- it was from an era
 when people thought that it was a good idea to hack a DSDT
 to workaround Linux failures and share the hacked DSDT
 with others.  That was a bad strategy and it should be abandoned.
 DSDT hacking is for Linux debugging only -- Linux should
 always be made to work with an un-modified DSDT.

I violently agree.

 yes, acpidump would be more useful than just the DSDT --
 as we get all kinds of issues with all the tables.
 
 One problem is that shipping around BIOS images, particularly
 modified ones, is sort of a touchy area.  This is the code
 of the manufacturer, who may or may not be happy that the
 community is hacking their code.  If any of those manufactureres
 got mad at Intel for mucking with their BIOS code,
 that would be a bad day for we Intel employees.
 
 lesswatts.org is hosted by Intel.  So we'd need to
 sort though this issue before adding an acpidump database.

Well, we have suspend.sf.net and the acpidump database can safely be put in
there, I think. ;-)

Greetings,
Rafael
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html