On Wed, Dec 05, 2018 at 11:48:37AM -0700, Logan Gunthorpe wrote: > > > On 2018-12-05 11:33 a.m., Jerome Glisse wrote: > > If i add a a fake driver for those what would i do ? under which > > sub-system i register them ? How i express the fact that they > > connect device X,Y and Z with some properties ? > > Yes this is exactly what I'm suggesting. I wouldn't call it a fake > driver, but a new struct device describing an actual device in the > system. It would be a feature of the GPU subsystem seeing this is a > feature of GPUs. Expressing that the new devices connect to a specific > set of GPUs is not a hard problem to solve. > > > This is not PCIE ... you can not discover bridges and child, it > > not a tree like structure, it is a random graph (which depends > > on how the OEM wire port on the chips). > > You must be able to discover that these links exist and register a > device with the system. Where else do you get the information currently? > The suggestion doesn't change anything to do with how you interact with > hardware, only how you describe the information within the kernel. > > > So i have not pre-existing driver, they are not in sysfs today and > > they do not need a driver. Hence why i proposed what i proposed > > a sysfs hierarchy where i can add those "virtual" object and shows > > how they connect existing device for which we have a sysfs directory > > to symlink. > > So add a new driver -- that's what I've been suggesting all along. > Having a driver not exist is no reason to not create one. I'd suggest > that if you want them to show up in the sysfs hierarchy then you do need > some kind of driver code to create a struct device. Just because the > kernel doesn't have to interact with them is no reason not to create a > struct device. It's *much* easier to create a new driver subsystem than > a whole new userspace API. So now once next type of device shows up with the exact same thing let say FPGA, we have to create a new subsystem for them too. Also this make the userspace life much much harder. Now userspace must go parse PCIE, subsystem1, subsystem2, subsystemN, NUMA, ... and merge all that different information together and rebuild the representation i am putting forward in this patchset in userspace. There is no telling that kernel won't be able to provide quirk and workaround because some merging is actually illegal on a given platform (like some link from a subsystem is not accessible through the PCI connection of one of the device connected to that link). So it means userspace will have to grow its own database or work- around and quirk and i am back in the situation i am in today. Not very convincing to me. What i am proposing here is a new common description provided by the kernel where we can reconciliate weird interaction. But i doubt i can convince you i will make progress on what i need today and keep working on sysfs. Cheers, Jérôme
