On 07/20/15 23:19, Gabriel L. Somlo wrote: > The code to build nested ksets (represending sub-sub-directories of > /sys/firmware/fw_cfg/...) and cleaning them up on exit doesn't promise > to be *too* horrible or bulky, but as I was getting ready to start > writing it, I realized that, in theory, nothing is to stop the fw_cfg > device from having files named e.g. > > "etc/foo" > > and > > "etc/foo/bar" > > That doesn't happen right now on the qemu side, but it could in > theory, and I have no idea how I'd deal with the file/directory > duality of "foo" in this situation, short of refusing to load the > module, or leaving out one fw_cfg file or the other. Unless there's > a way around this, I think it's safer to either stick with the default > 's/\//!/g' scheme of the kobject library, or implement something like > systemd's string escaping scheme that's been suggested earlier in this > thread... > > Or maybe leaving out the occasional poorly-named file is still better > than giving up the ability to run find on the fw_cfg sysfs folder ?
I assume once you have "etc/foo" in place (ie. as part of the filesystem), where "foo" is not a directory, then the attempt to create "etc/foo/bar" will cause whatever kernel API is in use to return ENOTDIR. Since you are checking return values anyway :), just barf a warning into syslog, and either skip the fw_cfg file, or abort module loading completely, as you see fit. This is a user error -- you should punish the user for it, not yourself. :) ... I just love "find", sorry. :) Anyway, I don't envision myself as a user of this feature any time soon, so please feel free to ignore me. Thanks Laszlo
