>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? > >> >And what exactly is in the other files? >> version is the hypervisor's version, the summery is data the user can extract >> in order to build a complete image of the system configuration > >Ok, those can be simple attribute groups, if they are static and do not >change. that's correct, all the information in the initial stage (system or board-wise) is static and per boot. > >> >> that I'd like to see under /sys/hypervisor >> > >> >/sys/hypervisor probably isn't the place for all of that mess. You are >> >going to have devices and a bus and all sorts of other complex things. >> from what I understand, when I add a sysfs tree to a device, it exists in side the device's full path. >> as the device can sit on different slots, it will have different path. >> to enable simpler data extraction, I'd like place it under a constant path, like every block device >> can be accessed via /sys/block > >Then you need to have a bus, or a class, as that is how you orginize >things. Please read the driver model chapter in the Linux Device >Drivers book as an example of the basic ideas here. I'll look it up > >> >Step back and explain exactly what you are trying to export, who will be >> >using it, and what format you want it in. This feels like a lot of >> >stuff that is probably not needed except for debugging. >> each instance of vSMP is comprised of logical partitions. >> the instance has it's own data required to be exported. >> each logical partition has it's own data required to be exported. >> that is why the above tree was suggested. > >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? also, how can organize the entries so they will appear under one location which is static? I'd prefer not adding complex code to the utils which need to traverse the sysfs tree to collect the right data > >> the data will be used by a layer that gather the information and exports it to ui and to scripts that log the info >> it isn't a debug info because there are some tools that need to know the a partition's information to run properly > >Ok, then they all need to be "one value per file" like sysfs requires. the current implementation does that exactly. each file represents one value either numerical or string Eial
