>From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> >Sent: Wednesday, April 20, 2022 15:17 >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: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? accessing the bar of an non existent device. thinking of it now, the api should return error in case the mapped region is not inited. > >> obliviously, this is not something accepted by the community. > >I do not understand what is not acceptable? a module crashing because a missing invariant testing > >> > >> >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? the end user > >> 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. that is why I think I should merge all the modules into one > >> > >> >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? per feature flexibility, for example, the ability to read logs via the device and display generic information each one is encapsulated inside a different module > >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... I understand, I'd prefer to understand all the aspects of the issues I'm facing before I load more code for you to go through as I assume that your time is precious Eial
