Cc: Benjamin Thery <benjamin.thery@...>, Greg Kroah-Hartman <gregkh@...>, Andrew Morton <akpm@...>, Daniel Lezcano <dlezcano@...>, Serge Hallyn <serue@...>, <linux-kernel@...>, Al Viro <viro@...>, Linux Containers <containers@...>
Potentially. I have no problem make it clear that things are more static.
See below.
Ah. When we are doing readdir or lookup. Yes that makes sense.
See below. I honestly think sysfs_tab_enabled is the wrong question.
So some concrete code examples here. In the current code in lookup
what I am doing is:
tag = sysfs_lookup_tag(parent_sd, parent->d_sb);
sd = sysfs_find_dirent(parent_sd, tag, dentry->d_name.name);
With the proposed change of adding tag types sysfs_lookup_tag becomes:
const void *sysfs_lookup_tag(struct sysfs_dirent *dir_sd, struct super_block *sb)
{
const void *tag = NULL;
if (dir_sd->s_flags & SYSFS_FLAG_TAGGED)
tag = sysfs_info(sb)->tag[dir_sd->tag_type];
return tag;
}
Which means that in practice I can lookup that tag that I am displaying
once.
Then in sysfs_find_dirent we do:
for (sd = parent_sd->s_dir.children; sd; sd = sd->s_sibling) {
if ((parent_sd->s_flags & SYSFS_FLAG_TAGGED) &&
(sd->s_tag.tag != tag))
continue;
if (!strcmp(sd->s_name, name))
return sd;
}
That should keep the implementation sufficiently inside of sysfs for there
to be no guessing. In addition as a practical matter we can only allow
one tag to be visible in a directory at once or else we can not check
for duplicate names. Which is the problem I see with a bitmap based test
too unnecessary many degrees of freedom.
The number of tag types will be low as it is the number of subsystems
that use the feature. Simple enough that I expect statically allocating
the tag types in an enumeration is a safe and sane way to operate.
i.e.
enum sysfs_tag_types {
SYSFS_TAG_NETNS,
SYSFS_TAG_USERNS,
SYSFS_TAG_MAX
};
I agree. Most of the implementation is in sysfs already. We just have
a few corner cases.
Fundamentally it is the subsystems responsibility that creates the
kobjects and the sysfs entries. The only case where I can see an
ida generated number being a help is if we start having lifetime
issues. Further the extra work to allocate and free tags ida based
tags seems unnecessary.
I don't doubt that there is a lot we can do better. My current goal
is for something that is clean enough it won't get us into trouble
later, and then merging the code. In tree where people can see
the code and the interactions I expect it will be easier to talk
about.
Currently the interface with the users is very small. Adding the
tag_type enumeration should make it smaller and make things more
obviously static.
Guys can we please make something useful happen?
Eric
--
