On Tue, Oct 26, 2010 at 11:49:26AM +0200, Markus Armbruster wrote: > Gleb Natapov <g...@redhat.com> writes: > > > On Mon, Oct 25, 2010 at 08:01:13PM +0200, Markus Armbruster wrote: > >> Gleb Natapov <g...@redhat.com> writes: > >> > >> > On Mon, Oct 25, 2010 at 05:06:51PM +0200, Markus Armbruster wrote: > >> >> Gleb Natapov <g...@redhat.com> writes: > >> >> > >> >> > Prevent two devices from claiming the same io port. > >> >> > >> >> Really? > >> >> > >> >> Your new check for double-claim is in the new isa_init_ioport(), which > >> >> is for ISADevice only. Thus, only qdevified ISA devices can opt for > >> >> this protection, by calling isa_init_ioport(). It doesn't protect from > >> >> devices who don't or can't opt in, such as PCI devices. > >> >> > >> > I didn't claim different. This obviously works only for ISA qdev > >> > devices. > >> > >> I read "Prevent two devices from claiming the same io port" as such. > >> > > And have you read subject with that? > > Yes. Nevertheless, I found it a bit misleading, so I commented. > Well, I hope it is clear now.
> >> >> Anyway, we already check for double-claim in > >> >> register_ioport_{read,write}(). The check has issues --- hw_error() is > >> >> wrong there for hot plug. But it's where the check should be, isn't it? > >> > You don't like double-claim checking? Forget about it (all 3 lines > >> > of code). The real point of the patch is to have ISA resources used > >> > by devices to be stored in common place (ISADevice) which allows > >> > get_dev_path() to be implemented. > >> > >> We already track I/O port use, in ioport.c. I don't like that > >> duplicated. Even less so if the dupe catches fewer double-claims than > >> the original. > > Consider it removed although we do keep track of irqs there and this > > tracking is also incomplete. Why is it there? > > Where's "there"? > In ISADevice. Look for "isabus->assigned" in isa-bus.c. > Let's not add to the code duplication if we can help it. It's bad > enough as it is. > > >> Perhaps your new function should wrap around register_ioport_*() instead > >> of supplementing it. > > register_ioport_*() is disconnected from qdev in general and from ISADEvice > > in particular, so how "wrap around register_ioport_*()" will help me to > > have get_dev_path() for ISABus is beyond my understanding. > > I was too terse, sorry. > > Maybe we should have functions for ISADevices to register ISA resources. > Functions that are *not* disconnected from qdev. Instead of code like > > register_ioport_write(pm_io_base, 64, 2, pm_ioport_writew, s); > register_ioport_read(pm_io_base, 64, 2, pm_ioport_readw, s); > register_ioport_write(pm_io_base, 64, 4, pm_ioport_writel, s); > register_ioport_read(pm_io_base, 64, 4, pm_ioport_readl, s); > isa_init_ioport_range(dev, pm_ioport_base, 64); > > or, with Avi's proposed interface > > ioport_register(&s->ioport, pm_io_base, 64); > isa_init_ioport_range(dev, pm_ioport_base, 64); > > we'd get something like > > isa_ioport_register(dev, &s->ioport, pm_io_base, 64); > > Isn't that neater? > Neater, but out of scope for my work. Obviously all resource management should go via qdev at the end. > Since some PCI devices also register ISA resources, we'd have to > offer functions for them as well, properly integrated. > > Now, I didn't mean to ask you to do all that as a precondition for > getting your patch in. I was just observing. OK. -- Gleb.