On Jul 11, 2012, at 9:47 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe <lacom...@gmail.com> wrote: >> Hi, >> >> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh <i...@bsdimp.com> wrote: >>> >>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: >>> >>>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh <i...@bsdimp.com> wrote: >>>>> >>>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh <i...@bsdimp.com> wrote: >>>>>>> >>>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more >>>>>>>> than one interface, and one of its child has need to use more than one >>>>>>>> interface, each interfaces cannot register, concurrently, its own >>>>>>>> ivar. While I try to always have a single child per >>>>>>>> interface/resource, I need to keep some compatibility with the old way >>>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>>>>>>> userland). So, it would have been nice if ivar had been per-interface, >>>>>>>> not global and unique to one device. >>>>>>> >>>>>>> There's one pointer for the ivars. The bus code gets to determine what >>>>>>> the ivar looks like, because the interface is totally private to the >>>>>>> bus. So long as it returns the right thing for any key that's >>>>>>> presented, it doesn't matter quite how things are done. >>>>>>> >>>>>>> So I'm not sure I understand what you are saying here. >>>>>>> >>>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to >>>>>> use both interfaces. There is no generic way for dev0 to export >>>>>> independent ivars for both interface. For now, I restricted the >>>>>> function of the second interface not to need ivar, but that's kind of >>>>>> hackish. >>>>> >>>>> Only if the IVARs for interface A and interface B have overlapping >>>>> values. If the Ivar keys don't overlap, then there's no problems at all. >>>>> Certainly less hackish than not using them at all. Since dev0 knows the >>>>> layout of the ivar that it set on its child, this presents no problems at >>>>> all. It would return the values from A from the right part of the ivar, >>>>> and those from B in the right part. Apart from the coordination of Ivar >>>>> numbers, as I outlined in my last post, there's no issue here. >>>>> >>>> I think we should not be talking about the same API here. I have no >>>> idea what you mean by "the key to value translation", nor "Ivar >>>> numbers". What I refer to is that device_set_ivars() / >>>> device_get_ivars() acts on a single instance variables from `struct >>>> device': `ivars'. In that case, I do not really see how to set that >>>> specific field to two distinct values for each interfaces. >>> >>> We are talking about the ivar interface. You are just misunderstanding how >>> it is used. >>> >> yes I indeed did... silly, silly me :-) >> > Actually, no. I wasn't that silly, neither was I misunderstanding > anything beside how *you* wanted it to be used, which is, I sorry to > say, unacceptable. The last thing I want is to pollute an interface > with a single-purpose, hand-crafted, bus. I was to just throw away all > that ivar stuff and go into hinted child configuration for now, > waiting for FDT... but of course, I figured out after a few hours that > hinted child attachment requires `bus_hinted_child' to be set in the > parent, as does bus_enumerate_hinted_children() / bus_generic_attach() > to explicitly pollute my code. All this stuff should be done > implicitly to support N:1 interfaces/client relationship. N > *independent* interfaces being provided by a single driver; of course, > I'm not even going back to require those interface being provided by > multiple drivers, it is already a dead end. > > I am not even sure any driver in the tree provides more than one interface... > > For whatever reason, I am more and more thinking that this all > new-bus[0] stuff is *way* overkill, static, bloated at will, and > missing critical features; a huge PITA to use, for the intended > purpose. > > /me pissed. > > - Arnaud > > [0]: damn, why is it even called "newbus", this stuff is 14 years old. > It really belongs to a museum, not production code...
I'm sorry you feel that way. Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI interfaces. Warner_______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
