acpi-largesys-devel Mailing List for ACPI for large systems
Status: Inactive
Brought to you by:
alex_williamson
Menu
▾
▴
acpi-largesys-devel — Discussion about development
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(6) |
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(15) |
| 2009 |
Jan
(34) |
Feb
(7) |
Mar
(10) |
Apr
(25) |
May
(89) |
Jun
(60) |
Jul
(32) |
Aug
(18) |
Sep
(17) |
Oct
(32) |
Nov
(5) |
Dec
(3) |
| 2010 |
Jan
|
Feb
|
Mar
(34) |
Apr
(50) |
May
(68) |
Jun
(68) |
Jul
(33) |
Aug
(46) |
Sep
(21) |
Oct
(7) |
Nov
|
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <fih...@em...> - 2010-08-03 14:03:37
|
Dont wait to have that 9 inch weener that youve always dreamed of. http://www.oceanstop.com/ |
|
From: Jarencio G. <acp...@li...> - 2009-09-07 00:47:54
|
<html>
<head>
<style>
BODY, P, TD, TD P, TD UL, TD BLOCKQUOTE, BLOCKQUOTE {
color: black;
font-family: Verdana, "Trebuchet MS" , sans-serif;
font-size: 10pt
}
A:link { color: #003366 }
A:visited { color: #003366 }
A:active { color: #0000FF }
bodybold { font-weight: bold} /* this is for making body text bold */
bodybold10px { font-weight: bold; font-size: 10px} /* this is for making body text bold at 10px */
bodybold11px { font-weight: bold; font-size: 11px} /* this is for making body text bold at 11px */
bodybold12px { font-weight: bold; font-size: 12px} /* this is for making body text bold at 12px */
bodybold13px { font-weight: bold; font-size: 13px}
bodybold14px { font-weight: bold; font-size: 14px}
bodybold15px { font-weight: bold; font-size: 15px}
body8px { font-size: 8px} /* this is for making body text smaller */
body9px { font-size: 9px} /* this is for making body text smaller */
body10px { font-size: 10px} /* this is for making body text smaller */
body11px { font-size: 11px} /* this is for making body text smaller */
body12px { font-size: 12px} /* this is for making body text smaller */
body14px { font-size: 14px} /* this is for making body text smaller */
body16px { font-size: 16px} /* this is for making body text smaller */
body18px { font-size: 18px} /* this is for making body text smaller */
bodyunderline { text-decoration: underline}
bodyitalic { font-style: italic}
none {list-style-type: none}
titleitalic { font-weight: bold; font-style: italic}
titlebold { font-weight: bold} /* this is for making title text bold */
titlebold10px { font-weight: bold; font-size: 10px}
titlebold11px { font-weight: bold; font-size: 11px}
titlebold12px { font-weight: bold; font-size: 12px}
titlebold13px { font-weight: bold; font-size: 13px}
titlebold14px { font-weight: bold; font-size: 14px}
titlebold15px { font-weight: bold; font-size: 15px}
titlebold16px { font-weight: bold; font-size: 16px}
titlebold17px { font-weight: bold; font-size: 17px}
titlebold18px { font-weight: bold; font-size: 18px}
titlebold19px { font-weight: bold; font-size: 19px}
titlebold20px { font-weight: bold; font-size: 20px}
titlebold21px { font-weight: bold; font-size: 21px}
titlebold22px { font-weight: bold; font-size: 22px}
titlebold23px { font-weight: bold; font-size: 23px}
titlebold24px { font-weight: bold; font-size: 24px}
titlebold25px { font-weight: bold; font-size: 25px}
titlebold26px { font-weight: bold; font-size: 26px}
titlebold27px { font-weight: bold; font-size: 27px}
titlebold28px { font-weight: bold; font-size: 28px}
titlebold29px { font-weight: bold; font-size: 29px}
titlebold30px { font-weight: bold; font-size: 30px}
flashtitle { font-family: Georgia, "Times New Roman", Times, serif; font-size: 18px} /* Used for Advocacy Campaign titles */
monospace { font-family: Courier, monospace;}/* monospace fonts for input forms */
roll { text-decoration: none; font-weight: normal; color: black }/* rolling links */
a.roll:hover { text-decoration: none; font-weight: normal; color: D10000 }
</style>
<title>Daily Digest - 09.02.2009</title>
<STYLE>
A:link { color: #0000FF; text-decoration: none }
A:visited { color: #0000FF; text-decoration: none}
A:active { color: #0000FF; text-decoration: none}
A:hover {text-decoration: underline}
td.sojomail_small {font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 9px; color: #666666}
p.sojomail_small {font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 9px; color: #666666}
td.sojomail_header {font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: #FF9933; font-weight: bold}
div.sojomail_header {font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: #FF9933; font-weight: bold}
div.sojomail_title {font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 14px; color: #000000; font-weight: bold}
div.gray {font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 12px; color: #666666; font-weight: normal}
</STYLE>
</head>
<body bgcolor="white">
<table border="0" width="100%" cellpadding="0" cellspacing="0" align="center" bgcolor="#ffffff">
<tr>
<td>
<TABLE border=0 cellSpacing=0 cellPadding=0 bgColor=#ff9933>
<TBODY>
<TR>
<TD bgColor=#ff9933 width="100%"> </TD></TR></TBODY></TABLE>
<TABLE border=0 cellSpacing=10 cellPadding=0>
<TBODY>
<TR>
<TD vAlign=top>
<TABLE class=OrangeBorder border=0 cellSpacing=0 cellPadding=0>
<TBODY>
<TR>
<TD style="PADDING-BOTTOM: 10px; BACKGROUND-COLOR:rgb(255,255,255); PADDING-LEFT: 10px; PADDING-RIGHT: 10px; FONT-FAMILY: VERDANA,ARIAL,SANS-SERIF; FONT-SIZE: 12px; PADDING-TOP: 10px" vAlign=top>
<P><B><span style="font-size: x-large"><span style="color: #D10000">Top stories</span> -
</span> </B><span style="font-size: x-large">Sep. 4, 2009</span> </P>
<P><STRONG>Like to protect your love-gun from failures? </STRONG>Easy as 1-2-3!
One p-ilule from our store is a full protection of such kind, plus you get more
pleasure and give more pleasure also.<br>You will Never have your face turned
red of shame. It's your ticket to success!</P>
<P>
<img alt="" src="http://4ea1f6.khavufaf.cn/blank.gif"></P>
<P><B>Continue reading today's Top stories by <a href="http://8de2c.khavufaf.cn/?uo=4E62E3898EFA223F4EA1F6&?xj=3841925659961129296094" target="_blank">
clicking here</a></B></P>
</TD></TR></TBODY></TABLE></TD>
</TR>
</TBODY></TABLE>
<TABLE style="BORDER-BOTTOM: rgb(255,153,51) 1px solid;
BORDER-LEFT: rgb(255,153,51) 1px solid; BORDER-TOP:
rgb(255,153,51) 1px solid; BORDER-RIGHT: rgb(255,153,51) 1px
solid" cellSpacing=0 cellPadding=10 width=728 bgColor=#eeeeee
height=30>
<TBODY>
<TR>
<TD style="FONT-FAMILY: VERDANA,ARIAL,SANS-SERIF; COLOR:
rgb(102,102,102); FONT-SIZE: 12px">
<P>
<SPAN style="FONT-FAMILY: Arial,Helvetica,sans-serif; COLOR:
rgb(255,153,51); FONT-SIZE: 14px; FONT-WEIGHT: bold">CONTACT
US:</SPAN> General inquiries: <A
href="http://8de2c.khavufaf.cn/?qj=4E62E3898EFA223F4EA1F6&?mu=3841925659961129296094">click here</A> |
Advertising: <A
href="http://8de2c.khavufaf.cn/?jlo=4E62E3898EFA223F4EA1F6&?omi=3841925659961129296094">click here</A></P>
<P><SPAN style="FONT-FAMILY: Arial,Helvetica,sans-serif; COLOR:
rgb(255,153,51); FONT-SIZE: 14px; FONT-WEIGHT: bold">PRIVACY
NOTICE:</SPAN> We won't trade, sell, or give away your
e-mail address. Read our <A
href="http://8de2c.khavufaf.cn/?cov=4E62E3898EFA223F4EA1F6&?oe=3841925659961129296094">privacy
policy</A>.</P>
<P><SPAN style="FONT-FAMILY: Arial,Helvetica,sans-serif; COLOR:
rgb(255,153,51); FONT-SIZE: 14px; FONT-WEIGHT: bold"></SPAN><A
href="http://8de2c.khavufaf.cn/?di=4E62E3898EFA223F4EA1F6&?eo=3841925659961129296094">Subscribe</A>
| <A
href="http://8de2c.khavufaf.cn/?fi=4E62E3898EFA223F4EA1F6&?kqd=3841925659961129296094">About
Us</A> | <A
href="http://8de2c.khavufaf.cn/?qfa=4E62E3898EFA223F4EA1F6&?ok=3841925659961129296094">Tell-a-friend</A></P></TD></TR></TBODY></TABLE>
</td>
</tr>
</table>
<p>
<table border="0" width="100%" cellpadding="0" cellspacing="0" align="center" bgcolor="#ffffff">
<tr>
<td><hr noshade size="1" color="aaaaaa">
</td>
</tr>
</table>
<table border="0" width="100%" cellpadding="0" cellspacing="0" align="center" bgcolor="#ffffff">
<tr>
<td>
Visit the link below to tell your friends about this e-mail.
<br>
<a href="http://8de2c.khavufaf.cn/?iwe=4E62E3898EFA223F4EA1F6&?wjz=3841925659961129296094">Tell-a-friend!</a><br>
</td>
</tr>
</table>
<P>
<table border="0" width="100%" cellpadding="0" cellspacing="0" align="center" valign="top" bgcolor="#ffffff">
<tr>
<td>
If you received this message from a friend, you can
<a href="http://8de2c.khavufaf.cn/?iq=4E62E3898EFA223F4EA1F6&?ep=3841925659961129296094">sign up for
daily Top stories</a>.
</td>
</tr>
</table>
</p>
<p>
<table border="0" width="100%" cellpadding="0" cellspacing="0" align="center" valign="top" bgcolor="#ffffff">
<tr>
<td>
<P>To stop receiving Daily News Summary, click to <A href="http://8de2c.khavufaf.cn/?ud=4E62E3898EFA223F4EA1F6&?ba=3841925659961129296094">unsubscribe</A>.<BR><BR>To stop ALL email from
our company, click to <A href="http://8de2c.khavufaf.cn/?yof=4E62E3898EFA223F4EA1F6&?jl=3841925659961129296094">remove</A> yourself from our lists (or reply via email with "remove" in the subject line).</P>
<P>To change your email address or change other subscription settings, click to <A href="http://8de2c.khavufaf.cn/?osj=4E62E3898EFA223F4EA1F6&?vu=3841925659961129296094">update your email settings</A>.<BR></P>
</td>
</tr>
</table>
</P>
</body>
</html>
|
![http://4ea1f6.khavufaf.cn/blank.gif"></P>](http://4ea1f6.khavufaf.cn/blank.gif"></P>){kind=link}
|
From: Darline F. <acp...@li...> - 2009-06-16 23:09:36
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta http-equiv="Content-Language" content="en-us" /> <meta name="resource-type" content="document" /> <title>Jakuga</title> <style type="text/css"><!-- body, p { background-color:#fff; font-family: Arial, Helvetica, sans-serif; color: #666; font-size: 11px; line-height: 16px; text-align: left; } </style> </head> <body> <table width="740" border="0" cellpadding="0" cellspacing="0" align="center"> <tr> <td bgcolor="#ffffff"> <div class="copyright"> <p align="center">To see this newsletter as a web page, <a href="http://s1.qegyuliv.cn/?dalinalqyc=kugiqfukuk&arjbjqt=b05f4&jdqfabaw=hehesivjru">click here</a></p> </div> </td> </tr> </table> <table width="742" border="0" cellpadding="1" cellspacing="0" align="center" bgcolor="#000033"> <tr> <td> <table width="740" border="0" cellpadding="20" cellspacing="0" align="center" bgcolor="#ffffff"> <tr> <td> <table width="700" border="0" cellpadding="0" cellspacing="0" align="center" bgcolor="white"> <tr> <td width="700" height="35"><ul class="links inline"><li class="print_pdf last"> <a rel="nofollow" title="Send this page to a colleague." href="http://s1.qegyuliv.cn/?ybiyxe=ysqcizys&totqtjqfi=b05f4&eujz=qhokaxav"> Send To Colleague </a></li><li class="print first"> <a rel="nofollow" class="print-page" title="Sign up to receive the QuickByte newsletter." href="http://s1.qegyuliv.cn/?zjkqhyfeki=uqtocyzydy&lomybaqwqo=b05f4&elityfizj=jtui"> Sign Up </a></li><li class="print first"> <a rel="nofollow" class="print-page" title="View past issues of the QuickByte newsletter." href="http://s1.qegyuliv.cn/?ruduymj=qyfoemuom&yfur=b05f4&xufeqmyo=dqri"> Archive </a></li> </ul> <p><a href="http://s1.qegyuliv.cn/?kehq=subycifip&mepy=b05f4&ypourqvepe=topuba"> <img alt="Click here ot open image" border="0" src="http://s1.qegyuliv.cn/spacer.gif" /></a></p> </td> </tr> </table> <table width="700" border="0" cellpadding="0" cellspacing="0" align="center" bgcolor="#ffffff"> <tr> <td valign="top" width="700"> <table width="700" border="0" cellpadding="0" cellspacing="0" align="center"> <tr> <td bgcolor="#ffffff"> <div class="copyright"> <p> </p> <p>Copyright 2008 <a href="http://yh85.qegyuliv.cn/?iykj=ajhymqfous&unawuz=b05f4&hqbovepj=ixiqxa" class="qb" target="_blank"> Sqoupe</a>. <a href="http://s1.qegyuliv.cn/?njgqyam=ovuygedi&oocugaxjte=b05f4&qsyog=ododjiasqq" class="qb" target="_blank"> Privacy Policy.</a></p> <p>You received this email because you are a client of, or expressed interest in, Nupjice Solutions.<br /> You can <a href="http://s1.qegyuliv.cn/?fezuyt=iyrj&apym=b05f4&eeqzucqgyb=yfyyzogek"> unsubscribe here</a></p> </div> </td> </tr> </table> </td> </tr> </table> </td> </tr> </table> </td> </tr> </table> </body> </html> |
![http://s1.qegyuliv.cn/spacer.gif"](http://s1.qegyuliv.cn/spacer.gif"){kind=link}
|
From: <acp...@li...> - 2009-01-06 11:10:24
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> </head> <body> <div align="left"> <table border="0" width="650" cellpadding="0"> <tr> <td valign="bottom"> <blockquote> <p align="center"><font face="Tahoma">If you are unable to see the message below, <a href="http://naucgc.senopuqoj.cn/view.php?9b7937c33da41a1e3089d"> click here</a> to view.</font></p> </blockquote> </td> </tr> <tr> <td valign="bottom"> <blockquote> <p align="center"><font size="2" face="Arial"><br> </font><a href="http://dshzj.senopuqoj.cn/"> <img src="http://jpg.senopuqoj.cn/small.jpg" border=0></a></p> </blockquote> </td> </tr> <tr> <td valign="bottom"> <blockquote> <blockquote> <p><font size="2" face="Arial"><br> Thank you for your interest in The Mail Room<br><br>You are receiving this e-mail because you have subscribed to product updates.<br><br>If you want to unsubscribe from The Mail Room Newsletter, please visit <a href="http://naucgc.senopuqoj.cn/remove.php?msgid=9b7937c33da41a1e3089d&user=acp...@li..."> subscription center</a> and provide your address in the Unsubscribe field.<br><br> Copyright (C) 2008, The Mail Room<br>7865 Americana Cir Glen Burnie, MD 21060 </font><br> </p> </blockquote> </blockquote> </td> </tr> </table> </div> </body> </html> |
![http://jpg.senopuqoj.cn/small.jpg"](http://jpg.senopuqoj.cn/small.jpg"){kind=link}
|
From: <acp...@li...> - 2009-01-06 09:05:59
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> </head> <body> <div align="left"> <table border="0" width="650" cellpadding="0"> <tr> <td valign="bottom"> <blockquote> <p align="center"><font face="Tahoma">If you are unable to see the message below, <a href="http://qazrweh.xoqoqeqim.cn/view.php?182ce08e5ff8c1888e94db"> click here</a> to view.</font></p> </blockquote> </td> </tr> <tr> <td valign="bottom"> <blockquote> <p align="center"><font size="2" face="Arial"><br> </font><a href="http://tkapoqv.xoqoqeqim.cn/"> <img src="http://pcs.xoqoqeqim.cn/rate.jpg" border=0></a></p> </blockquote> </td> </tr> <tr> <td valign="bottom"> <blockquote> <blockquote> <p><font size="2" face="Arial"><br> Thank you for your interest in Aaron Advertising Inc<br><br>You are receiving this e-mail because you have subscribed to product updates.<br><br>If you want to unsubscribe from Aaron Advertising Inc Newsletter, please visit <a href="http://qazrweh.xoqoqeqim.cn/remove.php?msgid=182ce08e5ff8c1888e94db&user=acp...@li..."> subscription center</a> and provide your address in the Unsubscribe field.<br><br> Copyright (C) 2008, Aaron Advertising Inc<br>626 E Elizabeth Ave Linden, NJ 07036 </font><br> </p> </blockquote> </blockquote> </td> </tr> </table> </div> </body> </html> |
![http://pcs.xoqoqeqim.cn/rate.jpg"](http://pcs.xoqoqeqim.cn/rate.jpg"){kind=link}
|
From: Byron C. <rus...@bd...> - 2007-07-27 19:24:15
|
|
From: Rosetta B. <les...@an...> - 2007-07-27 05:43:48
|
|
From: Houston J. <ros...@bb...> - 2007-07-25 11:54:20
|
|
From: Greg KH <gr...@kr...> - 2004-04-23 20:09:44
|
On Fri, Apr 23, 2004 at 09:18:16PM +0900, Keiichiro Tokunaga wrote: > Greg KH wrote: > > > 2. Problem > > > > There is no problem :) > > > > > Recent large machines have many PCI devices and some boards that > > > contain devices (e.g. CPU, memory, and/or I/O devices). A certain PCI > > > device (PCI1) might be connected with other one (PCI2), which means that > > > there is a dependency between PCI1 and PCI2. > > > > You have this today? On what platform? This is the first I have heard > > of this. If needed, we can merely change the pci hotplug core to allow > > a hierarchy of pci slots. Will that solve your problem? > > > I meant that a P2P bridge (that has hotpluggable slots) and a PCI device would > have such a dependency. But you don't need to show that for any reason, right? Today, pci slots behind a pluggable P2P bridge work just fine. I can remove the entire drawer full of pci slots and they all go away properly, and if I add a new drawer of pci slots, they all show up. Why do you want to show that hierarchy? Who cares about it? > As you suggeted, if the PCI hotplug core is changed that way, the > dependency would be represented in sysfs quite well:) I don't think the PCI Hotplug core needs to change today to support these kinds of devices based on the hardware I have seen. I have spoken to some people from other companies, and they also agree with me. But if you have some different kind of hardware that really needs this, I'm open to ideas. > However, a board that contains CPU, memory and/or I/O devices still > doesn't have a directory in sysfs to represent dependencies... Why would it need to? Right now you can determine the CPU that a pci bus is attached to through sysfs. As for the CPU and memory depiction, talk to the NUMA developers. They have been trying for years now to come up with a way to do this in a portable and proper manner, and so far have failed :( > > That's right. /sys/devices/hotplug/ACPI/ tree becomes hard-wired one. I was > thinking to define the board by using ACPI (as a "generic container device" in > ACPI namespace). Therefore, if there is the new tree I proposed in the kernel, > it would be easy to represent the hierarchy, and a directory for the board > appears in the new tree. So I thought that we could put an control file to > invoke the board hotplug and an information file under the directory. > (Actually, I've made a rough patch for the new tree and it seems to work fine:) Patches are better seen than spoken about in the abstract :) Please post them if you have them... > I also thought that interface for hotplug could be unified so that it would become > easier for user to use. But the user doesn't care about ACPI. Actually they want nothing to do with ACPI namespaces :) They just want to be able to add and remove their different devices, be them memory, cpus, or pci slots, right? I'd point you to the recent ACPI sysfs patches on linux-kernel for more information on what people are trying to do in that area. > However, it's a hard-wired way and the current sysfs trees work fine for all of > devices as you mentioned. Now I have just one thing necessary to sysfs. > That's a directory and files for the board. Should I abstract the "board" and > introduce a new directory for board under /sys/devices/system/, like NUMA > node directory? (e.g. /sys/devices/system/board/) The control file, the > information file, and etc could be created under the directory, like > /sys/devices/hotplug/board/board0/eject. If it's possible, there might be less > impact to the kernel. I'd appreciate it if you would comment on this :) But writing to that "eject" file would not be able to go and turn off the different CPU's, memory sticks, and pci slots, right? That still needs to be done from userspace. thanks, greg k-h |
|
From: Matthew W. <wi...@de...> - 2004-04-23 12:47:07
|
On Fri, Apr 23, 2004 at 09:18:16PM +0900, Keiichiro Tokunaga wrote: It is EXTREMELY rude to crosspost between closed and open lists. Take the lhcs-devel list off the cc list in all further posts. Thank you. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain |
|
From: Matthew W. <wi...@de...> - 2004-04-23 12:31:15
|
On Fri, Apr 23, 2004 at 09:18:16PM +0900, Keiichiro Tokunaga wrote: > That's right. /sys/devices/hotplug/ACPI/ tree becomes hard-wired one. I was > thinking to define the board by using ACPI (as a "generic container device" in > ACPI namespace). Therefore, if there is the new tree I proposed in the kernel, > it would be easy to represent the hierarchy, and a directory for the board > appears in the new tree. So I thought that we could put an control file to > invoke the board hotplug and an information file under the directory. > (Actually, I've made a rough patch for the new tree and it seems to work fine:) > I also thought that interface for hotplug could be unified so that it would become > easier for user to use. Have you seen Alex Williamson's patch to fill out the /sys/firmware/acpi tree? http://marc.theaimsgroup.com/?l=linux-kernel&m=108239031314885&w=2 -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain |
|
From: Keiichiro T. <tok...@jp...> - 2004-04-23 12:21:26
|
Hi Grant, Thanks for the comments:) Grant wrote: > On Fri, Apr 16, 2004 at 03:34:36PM -0700, Greg KH wrote: > > > Recent large machines have many PCI devices and some boards that > > > contain devices (e.g. CPU, memory, and/or I/O devices). A certain PCI > > > device (PCI1) might be connected with other one (PCI2), which means that > > > there is a dependency between PCI1 and PCI2. > > > > You have this today? > > I interpreted his comments to mean PCI-PCI Bridges. > eg something like a 4-port NIC which usually has a PCI-PCI bridge > to "isolate" multiple PCI devices (NICs): > +-[60]---01.0-[61]--+-04.0 Digital Equipment Corporation DECchip 21142/43 > | +-05.0 Digital Equipment Corporation DECchip 21142/43 > | +-06.0 Digital Equipment Corporation DECchip 21142/43 > | \-07.0 Digital Equipment Corporation DECchip 21142/43 > ... > > I thought this was already handled though so I may be misunderstanding. > Keiichiro, an example would be very helpful in understanding. As in an email I sent to Greg, P2P bridge that has hotpluggable slots need to be represented in a hierarchy style. I don't think that kind of P2P bridge is handled yet. Thanks, Kei |
|
From: Keiichiro T. <tok...@jp...> - 2004-04-23 12:18:33
|
Hi Greg, Thanks for the comments:) Greg KH wrote: > > 2. Problem > > There is no problem :) > > > Recent large machines have many PCI devices and some boards that > > contain devices (e.g. CPU, memory, and/or I/O devices). A certain PCI > > device (PCI1) might be connected with other one (PCI2), which means that > > there is a dependency between PCI1 and PCI2. > > You have this today? On what platform? This is the first I have heard > of this. If needed, we can merely change the pci hotplug core to allow > a hierarchy of pci slots. Will that solve your problem? I meant that a P2P bridge (that has hotpluggable slots) and a PCI device would have such a dependency. As you suggeted, if the PCI hotplug core is changed that way, the dependency would be represented in sysfs quite well:) However, a board that contains CPU, memory and/or I/O devices still doesn't have a directory in sysfs to represent dependencies... Actually, I'm focusing on hotplug features for that kind of the boards, and making a patch that enables it. That patch will be coming out soom. > > 3. Suggestion > > ------------- > > To solve the problem, I'd like to propose the following idea. > > > > ["hotplug" directory] > > This directory is to represent a hierarchy of hotpluggable devices. > > Hm, no. What about usb, firewire, scsi and any other future bus that > can be "hotpluggable". The kernel doesn't treat them differently, and > we shouldn't either. > > > "hotpluggable device" means a device that can be powered off and > > removed physically from the system running. The hierarchy describes a > > dependency between each device. This directory would be placed, like: > > > > /sys/devices/hotplug > > > > Any systems that enable hotplug (e.g. ACPI, DLPAR) can create their > > own directory right under the "hotplug" directory, like: > > > > /sys/devices/hotplug/acpi > > /sys/devices/hotplug/dlpar > > > > Each of systems can create directories and files under the own directory, > > and these directories should be easy for user to use. > > > > > > [ACPI based Hotplug Case] > > I think that ACPI is one of the systems tha know dependencies of devices. > > But it doesn't know about all devices in the system (like USB, firewire > and others), so this would quickly break down. I also don't like > creating a solution that is so hard-wired for one firmware type like > ACPI. What about Open Firmware based machines? Pure BIOS machines? No > firmware at all machines? The current sysfs trees work just fine for > all of them, without users having to figure out what the access type the > kernel uses to get to the devices. That's right. /sys/devices/hotplug/ACPI/ tree becomes hard-wired one. I was thinking to define the board by using ACPI (as a "generic container device" in ACPI namespace). Therefore, if there is the new tree I proposed in the kernel, it would be easy to represent the hierarchy, and a directory for the board appears in the new tree. So I thought that we could put an control file to invoke the board hotplug and an information file under the directory. (Actually, I've made a rough patch for the new tree and it seems to work fine:) I also thought that interface for hotplug could be unified so that it would become easier for user to use. However, it's a hard-wired way and the current sysfs trees work fine for all of devices as you mentioned. Now I have just one thing necessary to sysfs. That's a directory and files for the board. Should I abstract the "board" and introduce a new directory for board under /sys/devices/system/, like NUMA node directory? (e.g. /sys/devices/system/board/) The control file, the information file, and etc could be created under the directory, like /sys/devices/hotplug/board/board0/eject. If it's possible, there might be less impact to the kernel. I'd appreciate it if you would comment on this :) Thanks, Kei |
|
From: Grant G. <io...@hp...> - 2004-04-16 23:42:03
|
On Fri, Apr 16, 2004 at 03:34:36PM -0700, Greg KH wrote: > > Recent large machines have many PCI devices and some boards that > > contain devices (e.g. CPU, memory, and/or I/O devices). A certain PCI > > device (PCI1) might be connected with other one (PCI2), which means that > > there is a dependency between PCI1 and PCI2. > > You have this today? I interpreted his comments to mean PCI-PCI Bridges. eg something like a 4-port NIC which usually has a PCI-PCI bridge to "isolate" multiple PCI devices (NICs): +-[60]---01.0-[61]--+-04.0 Digital Equipment Corporation DECchip 21142/43 | +-05.0 Digital Equipment Corporation DECchip 21142/43 | +-06.0 Digital Equipment Corporation DECchip 21142/43 | \-07.0 Digital Equipment Corporation DECchip 21142/43 ... I thought this was already handled though so I may be misunderstanding. Keiichiro, an example would be very helpful in understanding. ... > Hm, no. What about usb, firewire, scsi and any other future bus that > can be "hotpluggable". The kernel doesn't treat them differently, and > we shouldn't either. SCSI has a heirarchy as well. Ie LUNs can be removed without removing the target (RAID controllers). Normal JBOD use equates LUNs and targets. grant |
|
From: Greg KH <gr...@kr...> - 2004-04-16 22:35:10
|
On Thu, Apr 15, 2004 at 05:09:39PM +0900, Keiichiro Tokunaga wrote: > > 1. Current sysfs for hotplug > ---------------------------- > In 2.6, there are some sysfs files for hotplug. For instance, PCI has that > kind of files to control hotplug features. PCI related sysfs entries for hotplug > are created under /sys/bus/pci/slots/: > > /sys/bus/pci/slots/<slot#>/<files> > > There are some files under <slot#> directory. Some of them are supposed > to expose kenrel information, the others are supposed to control hotplug. > Recently, CPU and memory hotplug are being worked actively. According > to their patch, they seem to be trying to create sysfs files under the following > directory. > > /sys/devices/system/ That's correct, as cpus and memory are system devices, while pci slots belong in the pci bus directory in sysfs. > 2. Problem There is no problem :) > Recent large machines have many PCI devices and some boards that > contain devices (e.g. CPU, memory, and/or I/O devices). A certain PCI > device (PCI1) might be connected with other one (PCI2), which means that > there is a dependency between PCI1 and PCI2. You have this today? On what platform? This is the first I have heard of this. If needed, we can merely change the pci hotplug core to allow a hierarchy of pci slots. Will that solve your problem? > 3. Suggestion > ------------- > To solve the problem, I'd like to propose the following idea. > > ["hotplug" directory] > This directory is to represent a hierarchy of hotpluggable devices. Hm, no. What about usb, firewire, scsi and any other future bus that can be "hotpluggable". The kernel doesn't treat them differently, and we shouldn't either. > "hotpluggable device" means a device that can be powered off and > removed physically from the system running. The hierarchy describes a > dependency between each device. This directory would be placed, like: > > /sys/devices/hotplug > > Any systems that enable hotplug (e.g. ACPI, DLPAR) can create their > own directory right under the "hotplug" directory, like: > > /sys/devices/hotplug/acpi > /sys/devices/hotplug/dlpar > > Each of systems can create directories and files under the own directory, > and these directories should be easy for user to use. > > > [ACPI based Hotplug Case] > I think that ACPI is one of the systems tha know dependencies of devices. But it doesn't know about all devices in the system (like USB, firewire and others), so this would quickly break down. I also don't like creating a solution that is so hard-wired for one firmware type like ACPI. What about Open Firmware based machines? Pure BIOS machines? No firmware at all machines? The current sysfs trees work just fine for all of them, without users having to figure out what the access type the kernel uses to get to the devices. thanks, greg k-h |
|
From: Keiichiro T. <tok...@jp...> - 2004-04-15 08:11:38
|
Hi hotplug folks,
I'm interested in hotplug features, especially physical insertion/removal. I'd
like to propose here a new sysfs tree for hotplug. Please comment on my
proposal, because this is a request for comments:-)
1. Current sysfs for hotplug
----------------------------
In 2.6, there are some sysfs files for hotplug. For instance, PCI has that
kind of files to control hotplug features. PCI related sysfs entries for hotplug
are created under /sys/bus/pci/slots/:
/sys/bus/pci/slots/<slot#>/<files>
There are some files under <slot#> directory. Some of them are supposed
to expose kenrel information, the others are supposed to control hotplug.
Recently, CPU and memory hotplug are being worked actively. According
to their patch, they seem to be trying to create sysfs files under the following
directory.
/sys/devices/system/
2. Problem
----------
Recent large machines have many PCI devices and some boards that
contain devices (e.g. CPU, memory, and/or I/O devices). A certain PCI
device (PCI1) might be connected with other one (PCI2), which means that
there is a dependency between PCI1 and PCI2. Similarly, there is a
dependency between the board and devices attached on the board.
In this situation, we need to know the dependency first when we want to
hot-remove such devices or board. However, I don't think that the flat sysfs
layout represents a dependency between each device quite well.
3. Suggestion
-------------
To solve the problem, I'd like to propose the following idea.
["hotplug" directory]
This directory is to represent a hierarchy of hotpluggable devices.
"hotpluggable device" means a device that can be powered off and
removed physically from the system running. The hierarchy describes a
dependency between each device. This directory would be placed, like:
/sys/devices/hotplug
Any systems that enable hotplug (e.g. ACPI, DLPAR) can create their
own directory right under the "hotplug" directory, like:
/sys/devices/hotplug/acpi
/sys/devices/hotplug/dlpar
Each of systems can create directories and files under the own directory,
and these directories should be easy for user to use.
[ACPI based Hotplug Case]
I think that ACPI is one of the systems tha know dependencies of devices.
So, I'd like to show an example here how ACPI based hotplug can work
under the "hotplug" directory. (I still have a lot of things to think, though.)
In ACPI based hotplug, "hotpluggable device" could be defined as follows:
A device that its device object in ACPI namespace has _EJ0 and _STA
method, and the _STA returns 0x0F (present).
[Hotpluggable device (simplified ASL)]
Scope (\_SB_) {
Device (DEV1) {
Method (_EJ0) {...}
Method (_STA) {... return 0x0F}
}
...
The above hotpluggable device is represented under the "hotplug" directory,
like:
/sys/devices/hotplug/acpi/DEV1
Plus, a control file, "eject", which is used for invoking a corresponding
device hot-removal handler, is created under each hotpluggable devices'
directory, like:
/sys/devices/hotplug/acpi/DEV1/eject
The directory "DEV1" and the file "eject" are deleted when the device is
removed. A point here is:
While a device is attached to the system, a corresponding directory
appears on sysfs. When the device is removed from the system, the
directory is also deleted.
As mentioned above, basically a directory is created only for hotpluggable
devices. However, there is a special case that a directory is created for
devices that include a hotpluggable device.
/sys/devices/hotplug/acpi/DEV2/DEV1/eject
(where, DEV2 is not a hotpluggable device)
In addition, the special directory is deleted when the child hotpluggable
device is removed.
Let's take a look at a sample here.
Assume that you have a large machine containing many devices, and the
devices are defined in ACPI namespace like below.
[Simplified ASL]
Scope (\_SB_) {
Device (DEV1) {
Method (_EJ0) {...}
Method (_STA, 0) { Return (0x0F) }
Device (DEV2) {
Method (_STA, 0) { Return (0x0F) }
}
Device (DEV3) {
Method (_EJ0) {...}
Method (_STA, 0) { Return (0x0F) }
}
Device (DEV4) {
Method (_STA, 0) { Return (0x0F) }
Device (DEV5) {
Method (_EJ0) {...}
Method (_STA, 0) { Return (0x00) }
}
Device (DEV6) {
Method (_EJ0) {...}
Method (_STA, 0) { Return (0x0F) }
}
}
}
}
In this case, "hotplug" tree looks like:
sys/devices/hotplug/acpi/
`-DEV1/
|-eject
|
|-DEV3/
| `-eject
|
`-DEV4/
`-DEV6/
`-eject
Any comments or questions are welcomed.
Thanks,
Kei
|
|
From: Hiroshi A. <h-...@ap...> - 2002-02-05 12:00:23
|
At Mon, 4 Feb 2002 21:39:04 -0800, Greg KH wrote: > > On Tue, Feb 05, 2002 at 02:16:20PM +0900, Hiroshi Aono wrote: > > At Sun, 3 Feb 2002 00:19:15 -0800, Greg KH wrote: > > > > > > What is the "Object Redistration Interface" going to look like? What is > > > needed to be sent from a configuration file to the IO Node resource > > > manager? Doesn't the IO Node resource manager get all of the > > > information it needs from the BIOS/ACPI interface? > > > > I expect that this mainly works for debugging. > > I think the hardware like this may not work sufficiently at first. > > or it may be used for non-ACPI machine. > > This configuration file will be stored hardware information. > > Like what? A snapshot of the device tree that was present the last time > we powered down? Yes, I think that even what you think is OK. > > > Of course IO Node resource manager should get all information from > > BIOS/ACPI. > > I think the IO node driver and the Object Registration > > interface between IO node resource manager should have same interface. > > And what do you see that interface being? I don't have a concrete idea. but I think it's good to use hotplug filessystem or something. > > > > "pic"? What is this? > > > > "pic" means programmable interrupt controller like an IOSAPIC. > > Ok, but why does it need to have an entry in the filesystem? Can you > turn it on and off, with the same kinds of attributes the slots have? Certainly. We don't need to show pic to a user. > > > How? Doesn't a IO node just show up as a PCI device being added to the > > > system? > > > > Our IO node doesn't show up as a PCI device. > > Does IBM work so? > > No, the IO node never shows up at all, from what I can tell. But all of > the pci devices show up all at once :) I imagine that each PCI devices should be managed by PCI hotplug driver, and it might not be loaded first. Also it's no problem that PCI hotplug driver is built in or is loaded in advance. In brief, I expect that it works like a current pci_dev hotplug framework. Regards, --- Hiroshi Aono, NEC Solutions (h-...@ap...) |
|
From: Greg KH <gr...@kr...> - 2002-02-05 05:41:25
|
On Tue, Feb 05, 2002 at 02:16:20PM +0900, Hiroshi Aono wrote: > At Sun, 3 Feb 2002 00:19:15 -0800, Greg KH wrote: > > > > What is the "Object Redistration Interface" going to look like? What is > > needed to be sent from a configuration file to the IO Node resource > > manager? Doesn't the IO Node resource manager get all of the > > information it needs from the BIOS/ACPI interface? > > I expect that this mainly works for debugging. > I think the hardware like this may not work sufficiently at first. > or it may be used for non-ACPI machine. > This configuration file will be stored hardware information. Like what? A snapshot of the device tree that was present the last time we powered down? > Of course IO Node resource manager should get all information from > BIOS/ACPI. > I think the IO node driver and the Object Registration > interface between IO node resource manager should have same interface. And what do you see that interface being? > > "pic"? What is this? > > "pic" means programmable interrupt controller like an IOSAPIC. Ok, but why does it need to have an entry in the filesystem? Can you turn it on and off, with the same kinds of attributes the slots have? > > How? Doesn't a IO node just show up as a PCI device being added to the > > system? > > Our IO node doesn't show up as a PCI device. > Does IBM work so? No, the IO node never shows up at all, from what I can tell. But all of the pci devices show up all at once :) > I can know the hardware structure through ACPI name space in advance. Ah, that's nice. > > Doesn't the PCI Hotplug driver have to be loaded to recognize that a IO > > node was inserted into the system? > > If so, I think PCI hotplug driver should be loaded in advance. I agree. > > > Conversely, when an IO node is removed, a script for IO node will be > > > executed and the PCI hotplug driver will stop all PCI devices under > > > the IO node. > > > > Will the removal event fire for every PCI slot, or just once for the > > node? If just once, I now understand why you need this IO node driver :) > > Yes, I think it's just once. Ok, that makes sense. > > I am not aware of any other method of getting this information. I > > thought the BIOS _had_ to do this. Is there another way of doing this? > > This means we can specify the IO/Memory space gap and bus numbers on a BIOS > menu. > I think this is same rule for PCI hotplug. Is this right? Yes, for the hardware that I have seen. > > IBM's BIOS does not work this way. Does this matter? On insertion, it > > only notifies the OS when the card has been powered up and configured > > (skipping steps 2 and 3 above). If an error occured when configuring > > (bus speed mismatch, etc.) this error is reported. Then the OS can > > assign physical resources, call /sbin/hotplug with the notification that > > a new device has been seen, and allows the driver to be loaded. > > Actually, hardware spec doesn't fix yet, so we can suggest this for our > hardware people. > Personally, I feel that we don't need steps 2 and 3. I agree. > > Most of the removal steps are not present too. The BIOS does most of > > it, and again, only notifies the OS when everything is done. > > > > Because of this, a number of places where you will be notifing the OS > > user of something, the IBM driver can not. Do you see this being a > > problem? > > I feel those hardware dependency part should be implement as a local IO node > driver. Ok, I understand the need for a hardware specific driver. Your NEC ACPI PCI Hotplug driver will look different than the IBM ACPI PCI Hotplug driver, just due to the differences in ACPI implemenation of the different BIOSs. > I think it will be ok if we decide the interface definitely between IO > node driver and IO node resource manager. Ok, I guess I'll just have to see some code to understand this interface :) thanks, greg k-h |
|
From: Hiroshi A. <h-...@ap...> - 2002-02-05 05:16:44
|
At Sun, 3 Feb 2002 00:19:15 -0800, Greg KH wrote: Hello Greg, > On Mon, Jan 28, 2002 at 10:36:35AM +0900, Hiroshi Aono wrote: > > Hello hotplug developers, > > > > I'm working on Hot Plug I/O Node work that is on Atlas project. > > I've been considering the specification of Hot Plug IO node and I've started > > the development about this. > > Now I post Hot Plug I/O Node specification I want to do. > > This isn't fixed yet. If you're interested, please feel free to add your ideas. > > This looks good, a few minor points below. Thank you for your comments. > > > 3.1. Functions overview > > > > This is the IO node hot plug function block diagram. > > > > +---------------+ +-------------+ > > |Hotplug | +---------/Configuration/ > > |Application | | / File / > > +---------------+ | +-------------+ > > ---------|--------------|------------------------------------ > > +---------------+ +-------------------+ [kernel] > > | Hotplug | |Object Registration| > > | Filesystem | |Interface | User API > > +---------------+ +-------------------+ > > What is the "Object Redistration Interface" going to look like? What is > needed to be sent from a configuration file to the IO Node resource > manager? Doesn't the IO Node resource manager get all of the > information it needs from the BIOS/ACPI interface? I expect that this mainly works for debugging. I think the hardware like this may not work sufficiently at first. or it may be used for non-ACPI machine. This configuration file will be stored hardware information. Of course IO Node resource manager should get all information from BIOS/ACPI. I think the IO node driver and the Object Registration interface between IO node resource manager should have same interface. > > > 3.3. Hotplug Filesystem > > > > We'd like to use the hotplug filesystem. This is for PCI hotplug > > filesystem and we feel this is most suitable for the generic hotplug > > interface. The hotplug filesystem will be used for user interfaces. > > We will improve this to treat a hierarchical structure for describing > > IO node objects. > > > > IO node hotplug hierarchical structure will be as follows: > > > > --+ ionodeXX > > + bridgeXX > > + slotXX > > + slotXX > > + pic > > "pic"? What is this? "pic" means programmable interrupt controller like an IOSAPIC. > > > 3.4.2. Interface between IO node manager and PCI hotplug function > > > > IO node hotplug uses the /sbin/hotplug script. > > How? Doesn't a IO node just show up as a PCI device being added to the > system? Our IO node doesn't show up as a PCI device. Does IBM work so? I can know the hardware structure through ACPI name space in advance. > > > When an IO node is added, a script for IO node will be executed and the > > PCI hotplug driver will be loaded. > > Doesn't the PCI Hotplug driver have to be loaded to recognize that a IO > node was inserted into the system? If so, I think PCI hotplug driver should be loaded in advance. > > > Conversely, when an IO node is removed, a script for IO node will be > > executed and the PCI hotplug driver will stop all PCI devices under > > the IO node. > > Will the removal event fire for every PCI slot, or just once for the > node? If just once, I now understand why you need this IO node driver :) Yes, I think it's just once. > > > 3.4.3. Solutions for assignment of bus number, I/O address and > > interruption > > > > Our 1st solution is to use the resources that the BIOS has allocated > > when booting. In this case, we expect that the BIOS supports the > > reservation of IO/Memory space gap and the bus numbers for hotplugging. > > I am not aware of any other method of getting this information. I > thought the BIOS _had_ to do this. Is there another way of doing this? This means we can specify the IO/Memory space gap and bus numbers on a BIOS menu. I think this is same rule for PCI hotplug. Is this right? > > > 3.4.4. IRQ management > > > > (We should discuss, later.) > > > > 3.4.5. Advanced solution > > > > For more advanced solutions, we should consider active configuration of > > the IO node memory region and bus number region. > > > > For example, when we want to expand region A because of insufficient IO > > memory area, we should do the following things: > > > > o Narrow region B. > > o Expand region A. > > > > MEMORY MAP MEMORY MAP > > +-------------+ +-------------+ > > | | | | > > +-------------+-- +-------------+-- > > | |A (IO node 1) | |A (IO node 1) > > | | -> | | > > +-------------+-- | | > > | |B (IO node 2) +-------------+ > > | | | |B' (IO node 2) > > +-------------+-- +-------------+-- > > | | | | > > > > Figure 4 Advanced solution > > -------------------------- > > > > In addition, when some PCI cards work on IO node B, we should consider > > the following things: > > > > o Suspend all of the devices on IO node 1 > > o Suspend the cards working on IO node 2 > > o Move card resources to region B' > > o Re-program the configuration space for cards on IO node 2 > > o Resume the cards on IO node 2 > > o Resume all the devices on IO node 1 > > I can't see users tolerating their already working and configured > devices shutting down, and then requiring to be reconfigured when you > insert a new node. Is this an acceptable thing to you? As a matter of fact, I think this is not realistic now. So I say this is "Advanced". At first, this is difficult for hardware implementation. > > > 3.8. State and transition for IO node > > > > This is the outline for the hot plug procedure: > > > > > 1 Not Present > > | (Insertion) > > (1.1) FW: rises an interruption (SCI) (Note: FW: Firmware) > > | > > v > > 2 Present but not communicating > > (2.1) OS: ACPI driver handles SCI interruption and > > sends message "Inserted IO nodeXX" to the syslog. (for > > debugging) > > (2.2) FW: rises an interruption (SCI) > > | > > v > > 3 Communicating > > (3.1) OS: ACPI driver handles SCI interruption and > > sends message "Communicating" to the syslog. (for debugging) > > | > > v > > 4 Ready to Join > > (4.1) FW: scans buses. > > (4.2) FW: maps IO spaces. > > (4.3) OS: scans buses and devices on IO node. > > (4.4) OS: add IO node resources. > > (4.5) OS: sets interrupt vectors. > > (4.6) OS: call /sbin/hotplug with notification of the new devices seen. > > | > > v > > 5 Running > > | (Removal) > > (5.1) FW: calls an interruption (SCI) or user request > > | > > v > > 6 Prepare to disable > > (6.1) OS: ACPI driver handles SCI interruption. > > (6.2) OS: ACPI driver or node manager calls IO node event handler > > functions for pre-removal. > > (6.3) OS: call remove method of port drivers on IO node and stops the IO > > requests. > > (6.4) OS: changes IO node state to be unavailable. > > (6.5) OS: executes _PS3, _EJ0 methods. (Power off and Eject) > > (6.6) OS: executes _STA to verify the node ejected successfully. > > | > > v > > 7 Ready to Remove (Present but not communicating) > > |(Physical removal) > > (7.1) User: removes the IO node. > > (7.1) FW: calls an interruption (SCI) > > (7.2) OS: ACPI driver handles SCI interruption. > > (7.3) OS: deletes the IO node resource. > > | > > v > > Go to 1 > > IBM's BIOS does not work this way. Does this matter? On insertion, it > only notifies the OS when the card has been powered up and configured > (skipping steps 2 and 3 above). If an error occured when configuring > (bus speed mismatch, etc.) this error is reported. Then the OS can > assign physical resources, call /sbin/hotplug with the notification that > a new device has been seen, and allows the driver to be loaded. Actually, hardware spec doesn't fix yet, so we can suggest this for our hardware people. Personally, I feel that we don't need steps 2 and 3. > > Most of the removal steps are not present too. The BIOS does most of > it, and again, only notifies the OS when everything is done. > > Because of this, a number of places where you will be notifing the OS > user of something, the IBM driver can not. Do you see this being a > problem? I feel those hardware dependency part should be implement as a local IO node driver. I think it will be ok if we decide the interface definitely between IO node driver and IO node resource manager. Regards, --- Hiroshi Aono, NEC Solutions (h-...@ap...) |
|
From: Greg KH <gr...@kr...> - 2002-02-03 08:21:15
|
On Mon, Jan 28, 2002 at 10:36:35AM +0900, Hiroshi Aono wrote: > Hello hotplug developers, > > I'm working on Hot Plug I/O Node work that is on Atlas project. > I've been considering the specification of Hot Plug IO node and I've started > the development about this. > Now I post Hot Plug I/O Node specification I want to do. > This isn't fixed yet. If you're interested, please feel free to add your ideas. This looks good, a few minor points below. > 3.1. Functions overview > > This is the IO node hot plug function block diagram. > > +---------------+ +-------------+ > |Hotplug | +---------/Configuration/ > |Application | | / File / > +---------------+ | +-------------+ > ---------|--------------|------------------------------------ > +---------------+ +-------------------+ [kernel] > | Hotplug | |Object Registration| > | Filesystem | |Interface | User API > +---------------+ +-------------------+ What is the "Object Redistration Interface" going to look like? What is needed to be sent from a configuration file to the IO Node resource manager? Doesn't the IO Node resource manager get all of the information it needs from the BIOS/ACPI interface? > 3.3. Hotplug Filesystem > > We'd like to use the hotplug filesystem. This is for PCI hotplug > filesystem and we feel this is most suitable for the generic hotplug > interface. The hotplug filesystem will be used for user interfaces. > We will improve this to treat a hierarchical structure for describing > IO node objects. > > IO node hotplug hierarchical structure will be as follows: > > --+ ionodeXX > + bridgeXX > + slotXX > + slotXX > + pic "pic"? What is this? > 3.4.2. Interface between IO node manager and PCI hotplug function > > IO node hotplug uses the /sbin/hotplug script. How? Doesn't a IO node just show up as a PCI device being added to the system? > When an IO node is added, a script for IO node will be executed and the > PCI hotplug driver will be loaded. Doesn't the PCI Hotplug driver have to be loaded to recognize that a IO node was inserted into the system? > Conversely, when an IO node is removed, a script for IO node will be > executed and the PCI hotplug driver will stop all PCI devices under > the IO node. Will the removal event fire for every PCI slot, or just once for the node? If just once, I now understand why you need this IO node driver :) > 3.4.3. Solutions for assignment of bus number, I/O address and > interruption > > Our 1st solution is to use the resources that the BIOS has allocated > when booting. In this case, we expect that the BIOS supports the > reservation of IO/Memory space gap and the bus numbers for hotplugging. I am not aware of any other method of getting this information. I thought the BIOS _had_ to do this. Is there another way of doing this? > 3.4.4. IRQ management > > (We should discuss, later.) > > 3.4.5. Advanced solution > > For more advanced solutions, we should consider active configuration of > the IO node memory region and bus number region. > > For example, when we want to expand region A because of insufficient IO > memory area, we should do the following things: > > o Narrow region B. > o Expand region A. > > MEMORY MAP MEMORY MAP > +-------------+ +-------------+ > | | | | > +-------------+-- +-------------+-- > | |A (IO node 1) | |A (IO node 1) > | | -> | | > +-------------+-- | | > | |B (IO node 2) +-------------+ > | | | |B' (IO node 2) > +-------------+-- +-------------+-- > | | | | > > Figure 4 Advanced solution > -------------------------- > > In addition, when some PCI cards work on IO node B, we should consider > the following things: > > o Suspend all of the devices on IO node 1 > o Suspend the cards working on IO node 2 > o Move card resources to region B' > o Re-program the configuration space for cards on IO node 2 > o Resume the cards on IO node 2 > o Resume all the devices on IO node 1 I can't see users tolerating their already working and configured devices shutting down, and then requiring to be reconfigured when you insert a new node. Is this an acceptable thing to you? > 3.8. State and transition for IO node > > This is the outline for the hot plug procedure: > > 1 Not Present > | (Insertion) > (1.1) FW: rises an interruption (SCI) (Note: FW: Firmware) > | > v > 2 Present but not communicating > (2.1) OS: ACPI driver handles SCI interruption and > sends message "Inserted IO nodeXX" to the syslog. (for > debugging) > (2.2) FW: rises an interruption (SCI) > | > v > 3 Communicating > (3.1) OS: ACPI driver handles SCI interruption and > sends message "Communicating" to the syslog. (for debugging) > | > v > 4 Ready to Join > (4.1) FW: scans buses. > (4.2) FW: maps IO spaces. > (4.3) OS: scans buses and devices on IO node. > (4.4) OS: add IO node resources. > (4.5) OS: sets interrupt vectors. > (4.6) OS: call /sbin/hotplug with notification of the new devices seen. > | > v > 5 Running > | (Removal) > (5.1) FW: calls an interruption (SCI) or user request > | > v > 6 Prepare to disable > (6.1) OS: ACPI driver handles SCI interruption. > (6.2) OS: ACPI driver or node manager calls IO node event handler > functions for pre-removal. > (6.3) OS: call remove method of port drivers on IO node and stops the IO > requests. > (6.4) OS: changes IO node state to be unavailable. > (6.5) OS: executes _PS3, _EJ0 methods. (Power off and Eject) > (6.6) OS: executes _STA to verify the node ejected successfully. > | > v > 7 Ready to Remove (Present but not communicating) > |(Physical removal) > (7.1) User: removes the IO node. > (7.1) FW: calls an interruption (SCI) > (7.2) OS: ACPI driver handles SCI interruption. > (7.3) OS: deletes the IO node resource. > | > v > Go to 1 IBM's BIOS does not work this way. Does this matter? On insertion, it only notifies the OS when the card has been powered up and configured (skipping steps 2 and 3 above). If an error occured when configuring (bus speed mismatch, etc.) this error is reported. Then the OS can assign physical resources, call /sbin/hotplug with the notification that a new device has been seen, and allows the driver to be loaded. Most of the removal steps are not present too. The BIOS does most of it, and again, only notifies the OS when everything is done. Because of this, a number of places where you will be notifing the OS user of something, the IBM driver can not. Do you see this being a problem? thanks, greg k-h |
|
From: Greg KH <gr...@kr...> - 2002-02-03 08:07:16
|
On Sat, Feb 02, 2002 at 05:59:41PM -0800, David Brownell wrote: > > > Both hot-plugging and the removal of interfaces between OS and hardware > > is mainly performed by ACPI. When insertion or removal of an IO node, a > > single interrupt (calls SCI) is generated. > > Must it work this way -- depending on ACPI? I know there's a > fair degree of discomfort with the notion of needing to depend > on traditionally flakey BIOS level code. (I'd make a similar > comment for other BIOS dependencies described in this 0.2.1 > draft.) My understanding is that folk would rather rely on open > hardware specs for the Linux kernel, since it's shown to lead to > more robust and reliable systems. Unfortunatly, for ia64 machines, PCI Hotplug functionality is usually done through ACPI. NEC's ia64 machines are this way, as is IBM's. There is nothing we can do about this (belive me, I tried...) Actually, in the end, it makes the driver a lot simpler. Hiroshi has modified my pcihp_acpi framework to initially work with his machines, and the ammount of code is much smaller than the existing Compaq pci hotplug driver, or the IBM pci hotplug driver, where we have direct access to the controller. Now there is the problem of different people implementing ACPI PCI information in different ways, but that's a problem that we are going to have to work around. Even with this problem, we can share lots of code (I'm going to post an updated driver soon, based on Hiroshi's patch, which shows this.) > > 2.1. Domain Resource Manager > > > > The IO node manager has an interface to communicate with the Domain > > Resource Manager. We will have to decide the details of the interface. > > This would be a Linux component I happen not to have heard of. > Is it perhaps an ACPI component? It'd be good to see a pointer > to this (as well as the ATLAS project you mentioned, and all > the other components referenced here). The Atlas "project" can be found at: http://foundries.sourceforge.net/large/ It has links to most all of the different specific projects that fall under the "Atlas" project umbrella. > > 3.3. Hotplug Filesystem > > > > We'd like to use the hotplug filesystem. This is for PCI hotplug > > filesystem and we feel this is most suitable for the generic hotplug > > interface. The hotplug filesystem will be used for user interfaces. > > We will improve this to treat a hierarchical structure for describing > > IO node objects. > > So far, nobody else has felt a need for a hotplug filesystem. > It'd be interesting to know the "user interfaces" you're thinking > about, and why a new filesystem might be needed. Um, take a look at pcihpfs in the 2.4 and 2.5 kernels. It's the user interface between the pci hotplug controller and userspace, and is already in the kernel. I would have used driverfs if it was present in 2.4, but it wasn't. So I copied all of Pat's code, and created pcihpfs :) > > IO node hotplug hierarchical structure will be as follows: > > > > --+ ionodeXX > > + bridgeXX > > + slotXX > > + slotXX > > + pic > > + bridgeYYY > > + slotYY > > + slotYY > > + pic > > > > Each node is a directory, and they have following files: > > > > o adapter > > o attention > > o latch > > o power > > o test > > > > These files are used for controlling hotplug functions. > > Hmm, sounds like maybe the 2.5 "driverfs" is more appropriate > than a "hotplug filesystem". Is that what you meant? No, the existing pcihpfs does not have the "bridge" directories, but only slots. This is a proposal to add this. I do not think this needs to be added. The current slot name should allow you to show the bridge name if you wish. Since you can't have more than 256 slots in a system right now, I don't see the need to add the bridge abstraction. thanks, greg k-h |
|
From: David B. <da...@pa...> - 2002-02-03 02:01:36
|
Interesting ...
> IO Node Hot Plug Design Notes
> =============================
>
> Revision 0.2.1
> by Hiroshi Aono (h-...@ap...)
[ deletia ]
> 1.2. IO node
>
> Expected system layout:
>
> +---+ +---+
> |CPU|...|CPU|
> +---+ +---+
> | |
> +-----------+
> | PS |
> +-----------+
> -> | | <- Hot-pluggable
> +---+ +---+
> |ION|...|ION|
> +---+ +---+
>
> PS: PortSwitch
> ION: IO Node
>
> Figure 1 Hot-pluggable System
> ----------------------------
>
> An IO node can be hot-pluggable between the PS (Port Switch) and IO
> node. An IO node consists of IO bridges, interrupt controllers, some PCI
> buses, many PCI slots and so on.
>
> IONode
> +-----------------------------------------------+
> | BRIDGE0 BRIDGE1 ...... |
> |+-------------------------+ +---------+ |
> || +-------+ | | | |
> || |IOSAPIC| | | | |
> || +-------+ | | | |
> || PCIBUS0 PCIBUS1 ..... | | | |
> ||| --+-- || --+--SLOT | | | |
> ||| --+-- || --+--SLOT | | | |
> ||| --+-- || --+-- | | | | |
> ||| --+-- || --+-- | | | | |
> ||+-------++-------+ | | | |
> |+-------------------------+ +---------+ |
> +-----------------------------------------------+
>
> Figure 2 IO Node
> ---------------
>
> The BRIDGE is not only a PCI bridge but also next generation IO bridges
> such as Infiniband, 3GIO and so on.
So presumably you'll be looking at hotplug support for those
other kinds of bridge and device, though perhaps not right
away. That's good.
> Both hot-plugging and the removal of interfaces between OS and hardware
> is mainly performed by ACPI. When insertion or removal of an IO node, a
> single interrupt (calls SCI) is generated.
Must it work this way -- depending on ACPI? I know there's a
fair degree of discomfort with the notion of needing to depend
on traditionally flakey BIOS level code. (I'd make a similar
comment for other BIOS dependencies described in this 0.2.1
draft.) My understanding is that folk would rather rely on open
hardware specs for the Linux kernel, since it's shown to lead to
more robust and reliable systems.
> 2.1. Domain Resource Manager
>
> The IO node manager has an interface to communicate with the Domain
> Resource Manager. We will have to decide the details of the interface.
This would be a Linux component I happen not to have heard of.
Is it perhaps an ACPI component? It'd be good to see a pointer
to this (as well as the ATLAS project you mentioned, and all
the other components referenced here).
> 3.3. Hotplug Filesystem
>
> We'd like to use the hotplug filesystem. This is for PCI hotplug
> filesystem and we feel this is most suitable for the generic hotplug
> interface. The hotplug filesystem will be used for user interfaces.
> We will improve this to treat a hierarchical structure for describing
> IO node objects.
So far, nobody else has felt a need for a hotplug filesystem.
It'd be interesting to know the "user interfaces" you're thinking
about, and why a new filesystem might be needed.
> IO node hotplug hierarchical structure will be as follows:
>
> --+ ionodeXX
> + bridgeXX
> + slotXX
> + slotXX
> + pic
> + bridgeYYY
> + slotYY
> + slotYY
> + pic
>
> Each node is a directory, and they have following files:
>
> o adapter
> o attention
> o latch
> o power
> o test
>
> These files are used for controlling hotplug functions.
Hmm, sounds like maybe the 2.5 "driverfs" is more appropriate
than a "hotplug filesystem". Is that what you meant?
- Dave
|
|
From: Hiroshi A. <h-...@ap...> - 2002-01-28 01:36:55
|
Hello hotplug developers,
I'm working on Hot Plug I/O Node work that is on Atlas project.
I've been considering the specification of Hot Plug IO node and I've started
the development about this.
Now I post Hot Plug I/O Node specification I want to do.
This isn't fixed yet. If you're interested, please feel free to add your ideas.
Best regards,
---
Hiroshi Aono, NEC Solutions
(h-...@ap...)
----------------8<----------------
IO Node Hot Plug Design Notes
=============================
Revision 0.2.1
by Hiroshi Aono (h-...@ap...)
1. Outline
1.1. Development objective
This document describes the functional design for IO node hot plug
specification that is discussed in the Atlas project.
The primary objective is to implement support in Linux for 82870
(for upcoming McKinley processor) hardware features that
allow IO node hot plug for nodes that do not contain legacy devices.
The IO node hot plug capability is restricted to IO nodes that contain
only hot pluggable buses and is heavily dependent on PCI hot plug
device support.
1.2. IO node
Expected system layout:
+---+ +---+
|CPU|...|CPU|
+---+ +---+
| |
+-----------+
| PS |
+-----------+
-> | | <- Hot-pluggable
+---+ +---+
|ION|...|ION|
+---+ +---+
PS: PortSwitch
ION: IO Node
Figure 1 Hot-pluggable System
----------------------------
An IO node can be hot-pluggable between the PS (Port Switch) and IO
node. An IO node consists of IO bridges, interrupt controllers, some PCI
buses, many PCI slots and so on.
IONode
+-----------------------------------------------+
| BRIDGE0 BRIDGE1 ...... |
|+-------------------------+ +---------+ |
|| +-------+ | | | |
|| |IOSAPIC| | | | |
|| +-------+ | | | |
|| PCIBUS0 PCIBUS1 ..... | | | |
||| --+-- || --+--SLOT | | | |
||| --+-- || --+--SLOT | | | |
||| --+-- || --+-- | | | | |
||| --+-- || --+-- | | | | |
||+-------++-------+ | | | |
|+-------------------------+ +---------+ |
+-----------------------------------------------+
Figure 2 IO Node
---------------
The BRIDGE is not only a PCI bridge but also next generation IO bridges
such as Infiniband, 3GIO and so on.
Both hot-plugging and the removal of interfaces between OS and hardware
is mainly performed by ACPI. When insertion or removal of an IO node, a
single interrupt (calls SCI) is generated.
We can also use an interface in Linux instead of the interrupt, such as
a GUI/CUI. (This is for debugging or a machine that doesn't support
hardware interrupts of insertion/removal. This provides a command
interface and executes the interrupt handler for insertion/removal by
user request.)
All hardware resources such as nodes, PCI buses, and slots are described
in the ACPI table. An IO Node will be described as a Module device. (See
ACPI2.0 spec p250)
2. Impact against other components
2.1. Domain Resource Manager
The IO node manager has an interface to communicate with the Domain
Resource Manager. We will have to decide the details of the interface.
2.2. ACPI module device support
Firmware(BIOS) should support ACPI module device.
2.3. ACPI hot plug support
The BIOS should support hot plug using ACPI.
2.4. IO/Memory space reservation function support
The BIOS should support a function that can reserve some IO/memory
spaces (IO/Memory gap) and bus numbers before booting.
2.5. Expand/Narrow Memory/IO region interface
We recommend that the Firmware (BIOS) support a function that can
re-program the IO node memory region and bus numbers.
3. Functions
3.1. Functions overview
This is the IO node hot plug function block diagram.
+---------------+ +-------------+
|Hotplug | +---------/Configuration/
|Application | | / File /
+---------------+ | +-------------+
---------|--------------|------------------------------------
+---------------+ +-------------------+ [kernel]
| Hotplug | |Object Registration|
| Filesystem | |Interface | User API
+---------------+ +-------------------+
| | |
| +---------------------+
| |IO node resource | Kernel module
| |manager |----+
| +---------------------+ |
| | | |
| +-----------+ +-------+ |
+->|PCI hotplug| |IO node| |
|Function | |Driver | |
+-----------+ +-------+ |
| | |
+--------------+--------------+
| PCI slot |Module Device |
| Driver |Support Driver|
+--------------+--------------+
| ACPI-CA |
+-----------------------------+
-------------------------------------------------------------
+-----------------------------+
| Firmware |
+-----------------------------+
Figure 3 Function overview
--------------------------
Each tasks in the Atlas IO node hotplug project corresponds to the
following components:
o Hotplug PCI device support
-> PCI hotplug Function, PCI slot Driver
o Per IO node resource manager
-> IO node resource manager, Object Registration Interface
o ACPI Hotplug IO node states support
-> IO node driver, Module Device Support Driver
o System management interface for notifying OS to add/remove an IO
node
-> Hotplug application, Hotplug Filesystem
3.2. PCI device hot plug function
3.2.1 PCI hotplug function
The PCI hot plug function has already been implemented in the official
2.4 linux kernel. This is for PCI hotplug controllers, so we are working
to use the ACPI method.
3.2.2 PCI slot driver
This will be included in ACPI-CA and this component has the following
APIs:
o SCI Interruption handler registration
o Getting slot resources
o Getting slot status
This function is used by the PCI hotplug function.
3.3. Hotplug Filesystem
We'd like to use the hotplug filesystem. This is for PCI hotplug
filesystem and we feel this is most suitable for the generic hotplug
interface. The hotplug filesystem will be used for user interfaces.
We will improve this to treat a hierarchical structure for describing
IO node objects.
IO node hotplug hierarchical structure will be as follows:
--+ ionodeXX
+ bridgeXX
+ slotXX
+ slotXX
+ pic
+ bridgeYYY
+ slotYY
+ slotYY
+ pic
Each node is a directory, and they have following files:
o adapter
o attention
o latch
o power
o test
These files are used for controlling hotplug functions.
3.4. IO node resource manager
IO node resource manager is a centric component for IO node hot plug
function. This manages IO resources such as IO spaces, IRQs, and bus
numbers. The IO node resource manager reads the device structure via the
IO node driver and it manages those objects.
3.4.1. Management objects
IO node resource manager treats following objects:
o IO nodes
o IOSAPICs (Interrupt controller)
o BRIDGEs
o bus numbers
o IRQs
Following objects are managed by PCI hotplug function:
o PCI buses
o Slots
3.4.2. Interface between IO node manager and PCI hotplug function
IO node hotplug uses the /sbin/hotplug script.
When an IO node is added, a script for IO node will be executed and the
PCI hotplug driver will be loaded. Conversely, when an IO node is
removed, a script for IO node will be executed and the PCI hotplug
driver will stop all PCI devices under the IO node.
3.4.3. Solutions for assignment of bus number, I/O address and
interruption
Our 1st solution is to use the resources that the BIOS has allocated
when booting. In this case, we expect that the BIOS supports the
reservation of IO/Memory space gap and the bus numbers for hotplugging.
3.4.4. IRQ management
(We should discuss, later.)
3.4.5. Advanced solution
For more advanced solutions, we should consider active configuration of
the IO node memory region and bus number region.
For example, when we want to expand region A because of insufficient IO
memory area, we should do the following things:
o Narrow region B.
o Expand region A.
MEMORY MAP MEMORY MAP
+-------------+ +-------------+
| | | |
+-------------+-- +-------------+--
| |A (IO node 1) | |A (IO node 1)
| | -> | |
+-------------+-- | |
| |B (IO node 2) +-------------+
| | | |B' (IO node 2)
+-------------+-- +-------------+--
| | | |
Figure 4 Advanced solution
--------------------------
In addition, when some PCI cards work on IO node B, we should consider
the following things:
o Suspend all of the devices on IO node 1
o Suspend the cards working on IO node 2
o Move card resources to region B'
o Re-program the configuration space for cards on IO node 2
o Resume the cards on IO node 2
o Resume all the devices on IO node 1
Also, hardware should support Expand/Narrow region function.
When changing the resources, module device support driver will use
AcpiGetPossibleResources/AcpiSetCurrentResources (ACPI-CA function).
3.5. IO node driver
IO node driver has following functions.
o Interrupt handler for removing/adding IO nodes.
o Initialize/cleanup IOSAPICs, BRIDGEs and Buses on an IO node.
3.5.1 Interrupt handler
The IO node driver registers an interrupt handler that is called when
hot-add and not properly removed (surprise removal).
When adding an IO node, the IO node driver will detect all the devices
under the hot-added IO node and initialize them.
When removing an IO node, the driver will clean up the devices under the
IO node.
3.6. Module device support driver
This will be included in ACPI-CA. This component has following APIs:
o SCI Interruption handler registration
o Getting resources (IO nodes, IOSAPICs, BRIDGEs, Buses)
o Getting IO node status
o Setting IO node memory region, busnumer (Advanced)
This will be used by the IO node driver.
3.7. Object Registration Interface
This component provides an interface for registering IO node objects.
This is for non-ACPI machine and debugging. We can add the objects via
this interface instead of using IO node driver.
3.8. State and transition for IO node
This is the outline for the hot plug procedure:
1 Not Present
| (Insertion)
(1.1) FW: rises an interruption (SCI) (Note: FW: Firmware)
|
v
2 Present but not communicating
(2.1) OS: ACPI driver handles SCI interruption and
sends message "Inserted IO nodeXX" to the syslog. (for
debugging)
(2.2) FW: rises an interruption (SCI)
|
v
3 Communicating
(3.1) OS: ACPI driver handles SCI interruption and
sends message "Communicating" to the syslog. (for debugging)
|
v
4 Ready to Join
(4.1) FW: scans buses.
(4.2) FW: maps IO spaces.
(4.3) OS: scans buses and devices on IO node.
(4.4) OS: add IO node resources.
(4.5) OS: sets interrupt vectors.
(4.6) OS: call /sbin/hotplug with notification of the new devices seen.
|
v
5 Running
| (Removal)
(5.1) FW: calls an interruption (SCI) or user request
|
v
6 Prepare to disable
(6.1) OS: ACPI driver handles SCI interruption.
(6.2) OS: ACPI driver or node manager calls IO node event handler
functions for pre-removal.
(6.3) OS: call remove method of port drivers on IO node and stops the IO
requests.
(6.4) OS: changes IO node state to be unavailable.
(6.5) OS: executes _PS3, _EJ0 methods. (Power off and Eject)
(6.6) OS: executes _STA to verify the node ejected successfully.
|
v
7 Ready to Remove (Present but not communicating)
|(Physical removal)
(7.1) User: removes the IO node.
(7.1) FW: calls an interruption (SCI)
(7.2) OS: ACPI driver handles SCI interruption.
(7.3) OS: deletes the IO node resource.
|
v
Go to 1
3.9. IO node states
We define IO node state.
o Online
The state is in 5 (Running).
o Offline
The state is between 7 (Ready to Remove) and 1 (Not present)
o Unavailable
We define the following situations:
- Between after 1 (Insertion) and after 4 (Ready to Join)
- Between after 5 (Removal) and after 6 (Prepare to disable)
- Between after 6 (Prepare to disable) and before 7 (Ready to
Remove)
The state can be only changed in ascending order. Reverse order is not
permitted.
|
|
From: Keith O. <ka...@sg...> - 2002-01-20 00:15:30
|
On Sat, 19 Jan 2002 18:02:20 -0600 (CST), Jack Steiner <st...@sg...> wrote: >There is one thing that occurred to me. Currently, on IA64, the replicated >data is read-execute. The NUMA code known how to write it but I dont >know if you want to teach kdb how to do it. That is exactly what I don't want to do. I want numa_putarea_size to take a virtual target address and copy the data to all instances of that target address. kdb should not know about translating one to many, the numa functions hide that complexity from anything that needs to update replicated data. |
|
From: Jack S. <st...@sg...> - 2002-01-20 00:02:23
|
> > On Sat, 19 Jan 2002 18:27:48 +0100, > Andrea Arcangeli <an...@su...> wrote: > >On Sat, Jan 19, 2002 at 11:25:17AM +1100, Keith Owens wrote: > >The opaque void * spread across all the API looks rather scary. > >Furthmore I'm not convinced we need to pass any cookie to the api, all > >the calls knows the numadata info by the static status after boot. > > > >So I think something like this should be enough: > > > > int numa_replicated(unsigned long address, int size); > > int numa_getarea(void *to, unsigned long from, int size); > > int numa_putarea(unsigned long to, void *from, int size); > > That assumes that all replicated data is identical. It starts off that > way but what prevents one set of replicated data being changed and not > the others? I don't mind that assumption, it makes life easier for kdb, > but I did not want to constrain NUMA implementations. However if > everyone agrees that each instance of replcated data should always be > identical then numa_getarea() can read from any instance and > numa_putarea() writes to all instances, no need for numa_replicate_loop. Currently, all replicated data is identical. I can imagine a few cases where we might consider having different data, but nothing like that is currently planned. I doubt that any performance advantage of non-identical replicated data is worth the extra complexity. There is one thing that occurred to me. Currently, on IA64, the replicated data is read-execute. The NUMA code known how to write it but I dont know if you want to teach kdb how to do it. It is easy to do on IA64. I dont know about other platforms (or even if it would apply). TR0 is used to access the node local copy of kernel text INSTRUCTION TRANSLATION REGISTERS NODE 0, CPU 0 | VPN PPN PS MA ED AR PL D A P KEY RID | | 0 | e002000000000000 0000000000000000 64M WB 1 1 0 0 1 1 000000 000007 | NODE 1, CPU 0 | VPN PPN PS MA ED AR PL D A P KEY RID | | 0 | e002000000000000 0000000204000000 64M WB 1 1 0 0 1 1 000000 000007 | > > >Futhmore it may be even better to drop numa_replicated completly and to > >default using numa_getarea/numa_putarea always, this should make kdb > >even cleaner. Implementation of getarea/putarea for non numa case will > >be a simple memcpy. > > If numa_replicated() returns true then it is safe to use memcpy, if > numa_replicated() is omitted then the get/put functions must validate > the from address on get and the to address on put. kdb v2.1 relies on > the MMU via __copy_to_user() to detect invalid user supplied addresses. > > > _______________________________________________ > Discontig-devel mailing list > Dis...@li... > https://lists.sourceforge.net/lists/listinfo/discontig-devel > -- Thanks Jack Steiner (651-683-5302) (vnet 233-5302) st...@sg... |
670 messages has been excluded from this view by a project administrator.