Closed davidker closed 8 years ago
In my opinion, all this stuff can be removed:
chipset_events
check_chipset_events()
clear_chipset_events()
visorchipset_holdchipsetready
chipsetready_store()
visorchipset_guest_attrs
visorchipset_guest_group
I also believe that a lot of the code that handles the storing of attributes from usermode is buggy, because it assumes that strings are '\0'-terminated, when in fact they might NOT be, and only count
bytes are valid.
Okay, issue it!!
From: selltc [mailto:notifications@github.com] Sent: Monday, March 14, 2016 6:48 AM To: davidker/unisys unisys@noreply.github.com Cc: Kershner, David A David.Kershner@unisys.com Subject: Re: [unisys] Get rid of unused code. (#14)
In my opinion, all this stuff can be removed:
chipset_events
check_chipset_events()
clear_chipset_events()
visorchipset_holdchipsetready
chipsetready_store()
visorchipset_guest_attrs
visorchipset_guest_group
I also believe that a lot of the code that handles the storing of attributes from usermode is buggy, because it assumes that strings are '\0'-terminated, when in fact they might NOT be, and only count bytes are valid.
— Reply to this email directly or view it on GitHubhttps://github.com/davidker/unisys/issues/14#issuecomment-196251910.
It seems it might be appropriate to just narrow the scope of this issue to handle the cleaning up of the sysfs attribute stuff, including removing unused code. So I will rename this issue accordingly. Feel free to name it otherwise if you disagree. I figure that we can add other issues to remove other instances of unused code when/if we find them.
Tim, remember that we have parahotplug user scripts when we clean things up.
And Tim, I want to keep the sysfs stuff that shows channel attributes because I want to make sure we can get them from the guest environment to compare with the SP. I think that is useful debugging information.
Tim, remember that we have parahotplug user scripts when we clean things up.
How do these get distributed with our upstream code? (Sorry, I'm probably having a brain cramp.)
the other user app is easy install
Greg committed this to staging-next on 4/29:
`static ssize_t chipsetready_store(struct device dev, struct device_attribute attr, const char *buf, size_t count) { char msgtype[64];
} `
Do we really need this in a guest? Isn't CALLHOMEDISK_MOUNTED just a Service Partition call? Modules_LOADED is that still needed when it gets loaded on demand?