[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [patch 5/5] xen: net features

  • To: "Jody Belka" <lists-xen@xxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Tue, 1 Feb 2005 01:54:57 -0000
  • Delivery-date: Tue, 01 Feb 2005 01:57:33 +0000
  • List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
  • Thread-index: AcUH/ei5zz3pb14NSKiaenCClyP38wAASnog
  • Thread-topic: [Xen-devel] [patch 5/5] xen: net features

> How about a sysfs attribute that we can push arbitary data into (up to
> a set maximum length) from xend? or maybe a sysfs attribute 
> folder, and
> then pass key=value pairs as the data, each of which appears 
> as an entry
> in the sysfs folder. Then you just use the interface name (which we
> obviously have in the hotplug script) to index into the sysfs tree.

I can't make my mind up on this. I can see how it would be useful to
have this information available, but I have a general aversion to
storing information in the kernel that doesn't strictly need to be

If we use the hotplug infrastructure, the only information we can
communicate via the standard scripts is the backend MAC address, which
in the case of a driver domain having a new client added dynamically
means that we'll have to have some mechansism to poke in a new
configuration file anyhow. Hence, I'm not sure the sysfs entries buy us


This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.