Having a single tag type per directory and thus a single tag visible per
directory does prevent multiple possible visible entries.
That is we can check when we add the sd if there will be a conflict in
the directory.
That is the abstraction now.
The only difference is how we represent the set of tags.
I use and array of the valid tags.
You use a bitmap.
And array allows the lookup of the tag I am looking for before
I search for the sd. An bitmap requires me to compare each entry.
For me that is a deal breaker. Currently in certain pathological
cases we have scaling issues with sysctl and sysfs that we can
have enormous directories that start running slowly. To fix
lookup performance requires that we know the full name before
we do the directory search which is the name string and the
tag.
So I having a type of tag as being of fundamental importance in
the interface now so we don't need to refactor all of the users
later. In addition to the fact that we need the type to know
how to set the tags when mounting a superblock and when
given a new kobject to create an sd for.
We could make the types dynamic rather then a static enumeration but
that seems needless complexity for now.
Sounds good. The only justification I can think of for ida tags is that
they are smaller, and so can keep the sysfs_dirents smaller. Which
occasionally is a significant concern. Still that should be an optimization
that we can apply later, as it is not a structural difference in the code.
Just to confirm. Do you the two operations:
mount_tag - called only when the sb is mounted
kobject_tag - called when we create new sd or rename an sd
Cause you to view an the tags as dynamic?
Eric
--
