On Wed, Apr 20, 2022 at 11:57:51AM +0000, Czerwacki, Eial wrote: > >From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > >Sent: Wednesday, April 20, 2022 14:42 > >To: Czerwacki, Eial <eial.czerwacki@xxxxxxx> > >Cc: linux-staging@xxxxxxxxxxxxxxx <linux-staging@xxxxxxxxxxxxxxx>; SAP vSMP Linux Maintainer <linux.vsmp@xxxxxxx> > >Subject: Re: [RFC] staging/vSMP: new driver > > > >On Wed, Apr 20, 2022 at 11:38:57AM +0000, Czerwacki, Eial wrote: > >> >From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > >> >Sent: Wednesday, April 20, 2022 14:24 > >> >To: Czerwacki, Eial <eial.czerwacki@xxxxxxx> > >> >Cc: linux-staging@xxxxxxxxxxxxxxx <linux-staging@xxxxxxxxxxxxxxx>; SAP vSMP Linux Maintainer <linux.vsmp@xxxxxxx> > >> >Subject: Re: [RFC] staging/vSMP: new driver > >> > > >> >On Wed, Apr 20, 2022 at 11:18:15AM +0000, Czerwacki, Eial wrote: > >> >> Greetings Greg, > >> >> > >> >> >From: Czerwacki, Eial <eial.czerwacki@xxxxxxx> > >> >> >Sent: Thursday, March 17, 2022 11:04 > >> >> >To: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > >> >> >Cc: linux-staging@xxxxxxxxxxxxxxx <linux-staging@xxxxxxxxxxxxxxx>; SAP vSMP Linux Maintainer <linux.vsmp@xxxxxxx> > >> >> >Subject: Re: [RFC] staging/vSMP: new driver > >> >> > > >> >> >>On Thu, Mar 17, 2022 at 08:52:37AM +0000, Czerwacki, Eial wrote: > >> >> >>> >> >What tasks? > >> >> >>> >> support of other information bits like stats > >> >> >>> > > >> >> >>> >I have no idea what that means :) > >> >> >>> in short, the hypervisor can provide stats it collects, future implementation will export that too > >> >> >> > >> >> >>The trick will be _how_ you export this information. Let's wait on that > >> >> >>one for now, your current api has lots of other questions to work out > >> >> >>first :) > >> >> > > >> >> >sure, thanks for all the help. > >> >> > > >> >> >Eial > >> >> > >> >> I was wondering, after I've switched the driver flow to the pci driver one, I lost the ability to prevent vsmp.ko from loading in case no device was found. > >> >> is there a way do to so? > >> > > >> >No, that is not how drivers have worked since the 2.4 kernel days (i.e. > >> >20 years ago?) It is fine for your driver to be loaded even if there is > >> >no device present. > >> > > >> >But, your driver will NOT be loaded automatically unless a device is > >> >found, so why would it be present in that situation? > >> > > >> >thanks, > >> > > >> >greg k-h > >> > >> because there are other modules which depends on it. > > > >I do not understand the question. > > > >> I guess I can detect it as part of the other module's init > > > >Huh? > > > >Try it and see, the linker will properly pull in the needed modules if > >you have symbols in one module that are needed by another one. > nothing prevents a user from loading the modules even if the device is missing. > the driver's hierarchy is one api modules and two unrelated modules which depend on it. > running modprobe vsmp_logs on a system where the device doesn't exists results with a kernel trace. What exact "kernel trace" is emitted? > obliviously, this is not something accepted by the community. I do not understand what is not acceptable? > > > >But if that is the case, why split them up into different modules? > splitting the driver into three modules is purely for flexibility reasons. Flexible for whom? > e.g. on runtime a user can decide which parts of the driver to run How? And why? A kernel driver should "just work" no need to configure anything or only load, or not load, a specific set of drivers. That's not how kernel modules work at all. > > > >I do not understand the question really. Try it and see first and if > >you have specific problems, please post the code and we will be glad to > >review it. > maybe I just need to forgo the flexibility and add all features as a built-in which isn't configurable What exact "flexibility" are you trying to do here? And again, nothing should be configured, it should always "just work" if the needed hardware is present. If not, nothing should happen. Again, post your code for better answers, this is all just hand-waving... thanks, greg k-h
