>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. obliviously, this is not something accepted by the community. > >But if that is the case, why split them up into different modules? splitting the driver into three modules is purely for flexibility reasons. e.g. on runtime a user can decide which parts of the driver to run > >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 Eial
