On Mon, Sep 05, 2022 at 12:02:47PM +0000, Czerwacki, Eial wrote: > >On Mon, Sep 05, 2022 at 07:28:02AM +0000, Czerwacki, Eial wrote: > >> >On Mon, Sep 05, 2022 at 06:07:07AM +0000, Czerwacki, Eial wrote: > >> >> > > >> >> >On Sun, Sep 04, 2022 at 02:37:32PM +0000, Czerwacki, Eial wrote: > >> >> >> Greetings, > >> >> >> > >> >> >> while working on a driver, I've found a bug that I'm unable to understand. > >> >> >> I assume that I'm doing something wrong. here is my reduced c file: > >> >> > > >> >> ><snip> > >> >> > > >> >> >I'll provide a better review after my coffee, but just one comment > >> >> >first. Ok, two: > >> >> > > >> >> >> #ifndef sysfs_emit > >> >> >> #define sysfs_emit sprintf > >> >> >> #endif // sysfs_emit > >> >> > > >> >> >Wait what? You mention at the end that you do nto have sysfs_emit in > >> >> >your kernel tree, but all activly maintained kernels does have this > >> >> >function. You should NEVER be working on a kernel tree that is not > >> >> >actually supported, and for new code like you are wanting to submit, you > >> >> >should always work on Linus's tree, or the last release, or something > >> >> >newer. > >> >> > > >> >> >Please move to 5.19 now, it will save you so much time later on... > >> >> well, I'm kinda binded to this kernel version buy you are right. > >> > > >> >What kernel version does not have sysfs_emit()? > >> SELS 15 SP2, it uses kernel 5.3.18-24.67 > > > >Ick, never work on an enterprise kernel for new stuff, they are crazy > >and you will need to usually redo your whole thing for upstream in the > >end. > > > >Just work off of the latest tree please and then backport when needed. > understood, that is the main focus now > > > > >> >> >Write the Documentation/ABI/ entries first, what do they look like for > >> >> >your new sysfs files? > >> >> > >> >> I thought that is my issue but wasn't sure. > >> >> what I'm looking for is this tree: > >> >> - vsmp > >> >> -- version > >> >> -- summery > >> >> --- data#1 > >> >> ... > >> >> --- data#n > >> >> -- boards > >> >> --- 0 > >> >> ---- data#1 > >> >> ... > >> >> ---- data#k > >> >> --- 1 > >> >> ... > >> >> --- l > >> >> > >> >> each board has a predefine set of attributes when I need to add another depending on the type. > >> >> also there are shared attributes between summery folder and the boards. that I was able to implement based on the name of the entry > >> > > >> >So "boards" are devices, and then you need a bus to manage them. Are > >> >you sure you need/want all of this? > >> no, boards are not devices, they logical partitions inside the hypervisor. > > > >Which can be a device, we have loads of virtual devices, it's how the > >driver model works. > > > >> each board has its own data I'd like to export. > > > >Then they should be treated as a device. > not sure I understand how they are connected, is there an example I can look at? The kernel has loads of busses and classes as real-world examples :) Think of it this way, each of your board will have a `struct device` in it, and then you will add them to the system. As you don't really have a complex thing, each board will just be bound to the "same" driver, and your bus will only have one driver, but that will allow them all to be enumerated and handled easily. And they will all hang off of the PCI device that you had here, it's up to you if you want to make a "bus device" in the middle or not like many busses do, but that's getting ahead a bit I think. Go read the documentation and try it out, there's a lot of concepts here that I think you need to learn up on in order to make this work well. Sorry it's not the simplest thing, but then again, it is an operating system :) And aren't there others at your company that can help you with this? > >Great, make them devices. > I still need to understand how to make them as devices. > if I understood you correctly, your suggestion is to run modprobe vsmp and there will be virtual device per board? > then for each I'll create the relevant sysfs entries? > if so, where can I find the global sysfs entries? What do you mean by "global" here? Just put those below /sys/hypervisor if you want, that should be simple, but not for the individual devices. > also, how can organize the entries so they will appear under one location which is static? The kernel device tree is never static. > I'd prefer not adding complex code to the utils which need to traverse the sysfs tree to collect the right data for device in $(ls /sys/bus/vsmp/device/); do that's not that hard :) thanks, greg k-h
