[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file

From: Laszlo Ersek
Subject: Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file
Date: Tue, 21 Jul 2015 00:07:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]