[Rpm-maint] FSM hooks for rpm plugin
elena.reshetova at intel.com
Thu Mar 7 13:59:53 UTC 2013
On 03/06/2013 05:01 PM, Reshetova, Elena wrote:
>> What's missing is that another call to the hook is needed in
>> fsmMkdirs() for the unowned directories, and there we should perhaps pass
>> in the "unowned"
>> aspect somehow. Having a separate argument for that seems like an
>> overkill though... maybe we could pass that piece of info in the
>> action argument instead. One possibility could be adding a new
>> action, eg FA_CREATEUNOWNED that could be used for unowned
>> directories (and files, but there aren't any currently). Or we could
>> define the action as a partial bitfield: leave the existing actions
>> alone but reserve the "upper" byte for special bits, such as
>> "unknown". I had some other use-case for turning it into (partial) bitfield
>> but can't remember what it was right now.
> I think bitfield would be better in this case: if one start introduce
> actions FA_CREATEUNOWNED, then why not have FA_CREATELINK and etc. I
> will add hook calling for mkdirs, but I think it is better that you do
> a change of actions in a separate commit.
>Sure, and I agree bitfield seems like the better option as it'll allow
>cramming a whole lot more information in there. There's a whole lot of
>redundancy in the current actions (all the skip cases for example) and some
>of the values are totally unused as well.
>As the file actions aren't really exported in the API in a way that somebody
>could actually be using them, we might be able to get away with just
>redefining the whole thing as a bitfield and add the old symbols as defines
>or'ed together from the bits. But I'll need to think about it some more, in
>any case such >a total conversion is not required in order to add a handful
>of bits right now.
Ok, I think if you can add an "unowned" bit to it for a start, this can be a
good beginning and then even the existing pre/post hooks can get one less
argument, which is great.
> Continue on bit field idea, it would be great for plugins to get the
> basic info about the file acted upon from action also: so , if we are
> adding unowned bit, should the basic bits indicating hard or sym link
> be also supplied in action? Like action could point that it is
> creation of symlink or removal of hard link. Is it too bad idea?
>Hmm, but we already pass the mode (and planning to pass the whole stat
>struct) around, so you can tell whether its a symlink, directory or something
>else. Hardlinks are the more special case but you can tell them apart from
>others by st_nlinks from the stat struct. Except that you dont necessarily
>know which one is "real" file without extra tracking... unless st_nlinks is 1
>for real >files (including the first
>hardlink) and more for the actual links. I'm not sure if that's the case even
>already, but should be possible to arrange at least.
I am quite sure you can't tell it from stat struct which is real file and
which is hard link: the value for st_nlinks is stored in inode and not in
dentry in my understanding, that's why it isn't really easy for plugin to
detect the hard links, so indicator would be a plus...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7220 bytes
Desc: not available
More information about the Rpm-maint