-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Udev methods consolidation #410
Conversation
1ea3476
to
e760f1a
Compare
e760f1a
to
f636806
Compare
# | ||
# @return [string] value corresponding to the key or empty string | ||
def udev_key_value(rule, key) | ||
raise ArgumentError if rule.nil? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is good practice to print also which argument have which problem so something like raise ArgumentError, "rule must not be nil" if rule.nil?
f636806
to
e9b02fa
Compare
|
||
SetModified() if current_rule != new_rule | ||
Items()[@current]["udev"] = { "net" => {} } if !Items()[@current]["udev"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add a log here maybe explaining that we are adding a new udev rule instead of replacing a new one, but this is also one the things i don't like about calling ReplateItemUdev for Items without udev rules.
|
What i mean is that we could add the default one in case GetItemUdevRule(@current).empty? directly |
Well I tried to split udev methods to basic ones and to some with additional complexity. Generating fallback / default rules belongs to those more complex in my POV. And I'm not sure if it should be generated immediately when reading udev rules or when user asks for device renaming. E.g. It requires some more investigation in udev but I wouldn't be surprised if udev "expects" (in modern linux) to each device having own udev rule - in such case we can use first approach. |
So now i think is time to remove the [WIP] from it an update bump version |
LGTM |
Purpose is to consolidate all udev rule handling methods at one place and design a shining new class for handling that.