On Sun, 2011-11-06 at 09:30 +0200, Michael S. Tsirkin wrote: > On Fri, Nov 04, 2011 at 04:53:05PM +0200, Sasha Levin wrote: > > > > > > As you said, the PCI cap list was introduced both to save space (which > > > > > > is not the motivation here), and because it's a very efficient > > > > > > > > > > It's actually pretty inefficient - there's an overhead of 3 bytes for > > > > > each vendor specific option. > > > > > > > > It's efficient because while you pay a small price for each optional > > > > option it also means that that option is optional and won't clutter the > > > > config space if it's not really in use. > > > > > > I guess my assumption is that most options will be in use, > > > not discarded dead-ends. > > > > I don't know about that. 64 bit features would be pretty rare for now - > > and I don't think that setting the alignment will be also enabled by > > default. > > Setting the alignment might not be *used* by default but > I think it must be enabled by default to allow bios access. > > > I think that we're looking at it differently because I assume that any > > feature we add at this point would be optional and used only in specific > > scenarios, while you think that everything added will be used most of > > the time. > > Options must often be present even if not used. For example, as device > has no way to know whether a guest will want to program alignment, it > has to make that option available. They should be enabled, but heres the difference between the two approaches is that if it's cap it simply won't be there, while in the other case it would just remain empty at some random offset of the struct. -- Sasha. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
