Mon, Nov 11, 2019 at 03:14:30PM CET, gregkh@xxxxxxxxxxxxxxxxxxx wrote: >On Mon, Nov 11, 2019 at 02:30:26PM +0100, Jiri Pirko wrote: >> Mon, Nov 11, 2019 at 04:46:01AM CET, jakub.kicinski@xxxxxxxxxxxxx wrote: >> >On Sun, 10 Nov 2019 10:18:55 +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote: >> >> > What I'm missing is why is it so bad to have a driver register to >> >> > multiple subsystems. >> >> >> >> Because these PCI devices seem to do "different" things all in one PCI >> >> resource set. Blame the hardware designers :) >> > >> >See below, I don't think you can blame the HW designers in this >> >particular case :) >> > >> >> > For the nfp I think the _real_ reason to have a bus was that it >> >> > was expected to have some out-of-tree modules bind to it. Something >> >> > I would not encourage :) >> >> >> >> That's not ok, and I agree with you. >> >> >> >> But there seems to be some more complex PCI devices that do lots of >> >> different things all at once. Kind of like a PCI device that wants to >> >> be both a keyboard and a storage device at the same time (i.e. a button >> >> on a disk drive...) >> > >> >The keyboard which is also a storage device may be a clear cut case >> >where multiple devices were integrated into one bus endpoint. >> >> Also, I think that very important differentiator between keyboard/button >> and NIC is that keyboard/button is fixed. You have driver bus with 2 >> devices on constant addresses. >> >> However in case of NIC subfunctions. You have 0 at he beginning and user >> instructs to create more (maybe hundreds). Now important questions >> appear: >> >> 1) How to create devices (what API) - mdev has this figured out >> 2) How to to do the addressing of the devices. Needs to be >> predictable/defined by the user - mdev has this figured out >> 3) Udev names of netdevices - udev names that according to the >> bus/address. That is straightforeward with mdev. >> I can't really see how to figure this one in particular with >> per-driver busses :/ > >Are network devices somehow only allowed to be on mdev busses? Of course not. But there is a difference if we are talking about: a) "the usual" network devices, like PF, VF. - They are well defined and they have well defined lifecycle (pci probe, sriov sysfs for number of VFs, etc). I this world all works fine. Even if a device has 100 static subdevices (bus or no bus). b) dynamically created sub-bar-devices or subfunctions. Could be created by user. This is not handled now in kernel, we have to find correct iface. I don't really care it it is fakebus, driverbus, etc. I'm just concerned about how to handle 1), 2), 3) above. > >No, don't be silly, userspace handles this just fine today on any type >of bus, it's not an issue. > >You don't have to like individual "driver busses", but you had better >not be using a fake platform device to use mdev. That's my main >objection... Okay, I understand your objection. Do you have suggestion how to handle 1) 2) 3) from above? > >thanks, > >greg k-h
