Hi everyone,

Let's recapitulate a little software engineering:

Sourcecode costs money to maintain. In the case of Linux we are all
investing our time (= money) in this. The costs can be expressed 
in a formula like:

                 hardness * size
    costs = C *  ---------------
                    quality

Where 
        C is a constant factor, 
        hardness is large for sytem programming, low for trivial applications, 
        size is the size of the sourcecode in lines. 
and     quality is a measure of the quality of the programming.

In the case of Linux, size is still quite modest (13000 lines), hardness is 
high, we are dealing with an OS, and quality is high (Good programming Linus!).

To reduce maintaining costs, you can influence the two parameters in this 
equation: the size and the quality. The quality is a very hard parameter
to influence, except for that you should attempt to keep it as high as 
possible. However the size parameter is easily influencable in some cases:

for instance, block_read () and block_write () are almost completely identical,
however they are separate routines. If they are merged, the complexity of the
code will increase slightly, (decreasing quality a little), but the size
of the source code will decrease significantly (on this section of the code).

That the maintaining costs of such "identical" routines are really higher
than those for smaller routines, can be demonstrated with an example:
In block_write () some local variables are declared as:

        unsigned int block = filp->f_pos >> BLOCK_SIZE_BITS;
        unsigned int offset = filp->f_pos & (BLOCK_SIZE-1);
        unsigned int chars;
        unsigned int size;

and in block_read () as:

        int block = filp->f_pos >> BLOCK_SIZE_BITS;
        int offset = filp->f_pos & (BLOCK_SIZE-1);
        int chars;
        int size;

I suspect that this is not what was intended, and someone corrected the 
block_write case, but not the block_read . Similar pieces of code
can be found for reading/writing of character devices.  

I propose to merge these very similar routines, and reduce the code
size, being careful not to increase complexity too much.


                                                Roger
-- 
If the opposite of "pro" is "con", what is the opposite of "progress"? 
        (stolen from  kadokev@iitvax ==? technews@iitmax.iit.edu)
EMail:  wolff@duteca.et.tudelft.nl   ** Tel  +31-15-783644 or +31-15-142371