Hi Greg,
First of all thanks for your reply.
On Tue, 14 Mar 2017, Greg Kroah-Hartman wrote:
On Mon, Mar 13, 2017 at 03:14:12PM -0700, Till Smejkal wrote:
There's no way with that many cc: lists and people that this is really
making it through very many people's filters and actually on a mailing
list. Please trim them down.
I am sorry that the patch's cc-list is too big. This was the list of people that the
get_maintainers.pl script produced. I already recognized that it was a huge number of
people, but I didn't want to remove anyone from the list because I wasn't sure who
would be interested in this patch set. Do you have any suggestion who to remove from
the list? I don't want to annoy anyone with useless emails.
Minor sysfs questions/issues:
quoted
+struct vas {
+ struct kobject kobj; /* < the internal kobject that we use *
+ * for reference counting and sysfs *
+ * handling. */
+
+ int id; /* < ID */
+ char name[VAS_MAX_NAME_LENGTH]; /* < name */
The kobject has a name, why not use that?
The reason why I don't use the kobject's name is that I don't restrict the names that
are used for VAS/VAS segments. Accordingly, it would be allowed to use a name like
"foo/bar/xyz" as VAS name. However, I am not sure what would happen in the sysfs if I
would use such a name for the kobject. Especially, since one could think of another
VAS with the name "foo/bar" whose name would conflict with the first one although it
not necessarily has any connection with it.
quoted
+
+ struct mutex mtx; /* < lock for parallel access. */
+
+ struct mm_struct *mm; /* < a partial memory map containing *
+ * all mappings of this VAS. */
+
+ struct list_head link; /* < the link in the global VAS list. */
+ struct rcu_head rcu; /* < the RCU helper used for *
+ * asynchronous VAS deletion. */
+
+ u16 refcount; /* < how often is the VAS attached. */
The kobject has a refcount, use that? Don't have 2 refcounts in the
same structure, that way lies madness. And bugs, lots of bugs...
And if this really is a refcount (hint, I don't think it is), you should
use the refcount_t type.
I actually use both the internal kobject refcount to keep track of how often a
VAS/VAS segment is referenced and this 'refcount' variable to keep track how often
the VAS is actually attached to a task. They not necessarily must be related to each
other. I can rename this variable to attach_count. Or if preferred I can
alternatively only use the kobject reference counter and remove this variable
completely though I would loose information about how often the VAS is attached to a
task because the kobject reference counter is also used to keep track of other
variables referencing the VAS.
quoted
+/**
+ * The sysfs structure we need to handle attributes of a VAS.
+ **/
+struct vas_sysfs_attr {
+ struct attribute attr;
+ ssize_t (*show)(struct vas *vas, struct vas_sysfs_attr *vsattr,
+ char *buf);
+ ssize_t (*store)(struct vas *vas, struct vas_sysfs_attr *vsattr,
+ const char *buf, size_t count);
+};
+
+#define VAS_SYSFS_ATTR(NAME, MODE, SHOW, STORE) \
+static struct vas_sysfs_attr vas_sysfs_attr_##NAME = \
+ __ATTR(NAME, MODE, SHOW, STORE)
__ATTR_RO and __ATTR_RW should work better for you. If you really need
this.
Thank you. I will have a look at these functions.
Oh, and where is the Documentation/ABI/ updates to try to describe the
sysfs structure and files? Did I miss that in the series?
Oh sorry, I forgot to add this file. I will add the ABI descriptions for future
submissions.
quoted
+static ssize_t __show_vas_name(struct vas *vas, struct vas_sysfs_attr *vsattr,
+ char *buf)
+{
+ return scnprintf(buf, PAGE_SIZE, "%s", vas->name);
It's a page size, just use sprintf() and be done with it. No need to
ever check, you "know" it will be correct.
OK. I was following the sysfs example in the documentation that used scnprintf, but
if sprintf is preferred, I can change this.
Also, what about a trailing '\n' for these attributes?
I will change this.
Oh wait, why have a name when the kobject name is already there in the
directory itself? Do you really need this?
See above.
quoted
+/**
+ * The ktype data structure representing a VAS.
+ **/
+static struct kobj_type vas_ktype = {
+ .sysfs_ops = &vas_sysfs_ops,
+ .release = __vas_release,
Why the odd __vas* naming? What's wrong with vas_release?
I was using the __* naming scheme for functions that have no other meaning outside of
my source file. But I can change this if people don't like it. I have no strong
feelings about the names of the functions.
quoted
+ .default_attrs = vas_default_attr,
+};
+
+
+/***
+ * Internally visible functions
+ ***/
+
+/**
+ * Working with the global VAS list.
+ **/
+static inline void vas_remove(struct vas *vas)
<snip>
You have a ton of inline functions, for no good reason. Make them all
"real" functions please. Unless you can measure the size/speed
differences? If so, please say so.
There was no specific reason why I declared the functions as inline except my hope to
reduce the function call for some of my very small functions. I can look more closely
at this and check whether there is some real benefit in inlining them and if not
remove it.
Thank you very much.
Till
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>