From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: Re: Proposal for init/kexec/hotplug format for Xen Date: Tue, 01 Mar 2005 00:02:08 +1100 Message-ID: <1109595728.7090.25.camel@localhost.localdomain> References: <1463693.1109593362044.JavaMail.www@wwinf3101> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit In-Reply-To: <1463693.1109593362044.JavaMail.www@wwinf3101> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: harry@hebutterworth.freeserve.co.uk Cc: Anthony Liguori , Keir Fraser , Jeremy Katz , Xen Mailing List List-Id: xen-devel@lists.xenproject.org On Mon, 2005-02-28 at 13:22 +0100, harry@hebutterworth.freeserve.co.uk wrote: > Why have two separate mechanisms when the mechanism required for > hotplug can be used to build the tree from scratch? The only difference would be the transport for hotplug events, which is infrastructure which needs to exist anyway to transport other information between domains. We'll see when the code's finished, but I see the code being: __init boot_devtree_setup() { devtree_add(boot_devtree_ptr); } hotplug_receive_event() { receive data if (op == ADD) devtree_add(data); else if (op == REMOVE) devtree_remove(data); } ie. the mere difference in transport should be a few lines of code. Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click