[Rpm-maint] FSM hooks for rpm plugin

Reshetova, Elena 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...

Best Regards,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7220 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20130307/45e86ed5/attachment.p7s>

More information about the Rpm-maint mailing list