I have been putting alot of effort into going through the filesystem code
and hand-optimising it to make it smaller, and am currently doing pretty
well. I have come across two issues which I think I can exploit to greatly
reduce the code size, but I thought I would put them before the list
before I start hacking the code apart.
Firstly, all the inode operations with, I think, only one exception, are
passed an inode, which is usually a directory. The operation is expected to
call iput() in this inode if it is valid before it returns. This often
leads to iput being called many times within the inode op function, and
also if the inode operation is not called it has to be called in the
function that calls the inode operation. I propose that this could be
simplified by specifying that inode operations should not call iput() and
it should instead be done by the calling function, and would therefor only
need to be done once, and it would not be necessary to increment the
refcount artificially. Could anyone with a good understanding of the fs
code comment on this? I would particularly like to here what Alan thinks.
Secondly there are many places in the code where pointers are checked to
see if they are NULL. Frequently the result is not fatal, but by inspecting
the code, it should not be possible for that pointer to be NULL in that
location. I propose to replace these checks with a macro which causes a
kernel panic if it detects NULL, but which can set to do nothing, thus
minimising the code size in a production build. This is frequently done in
many projects by using the assert() macro. Please let me know what you
think.
Al
