Re: Fwd: struct inode size reduction.

[Andries Brouwer <aebr@win.tue.nl>]

On Mon, Mar 10, 2003 at 11:58:17AM +0100, Roman Zippel wrote:

> > -       error = register_chrdev(driver->major, driver->name, &tty_fops);
> > +       error = register_chrdev_region(driver->major, driver->minor_start,
> > +                                      driver->num, driver->name, &tty_fops);
> 
> Are that much parameters really needed?

Yes.

If you want to follow Al you would write
	MKDEV(driver->major, driver->minor_start)
instead of this
	driver->major, driver->minor_start
and you would have one parameter less.

Andries


[I wrote Al and wanted to cc l-k but typoed. Let me copy this letter
for information purposes and to show that we do not want to write MKDEV.]

-------------------------------------------------------------------------
Some more comments on types and their structure.

As you know very well, I had a setup in the ancient times
with a kdev_t that was a pointer, and

#define MINOR(dev)      (dev)->minor

That was nice and well - you thought that a refcount
was needed, I thought that with the given rules for use
it was possible to prove that no refcount was needed,
and the discussion was never settled.
If we ever meet FTF we can fight that fight.

In the below I will use kdev_t again, but now with an
entirely different meaning, not a pointer but an
arithmetic type.

User space (programs, file systems) has many dev_t
instances that must remain valid. So, when dev_t
changes size the 16-bit values must keep their old
major and minor. This means that for a dev_t the
operations MINOR, MAJOR, MKDEV are not completely trivial.
They involve tests on whether the value fits into 16 bits.
E.g.

#define MKDEV(ma,mi)   ((dev_t)(((((ma) & ~0xff) == 0) && (((mi) & ~0xff) == 0
)) ? (((ma) << 8) | (mi)) : (((ma) << DEV_MINOR_BITS) | (mi))))

This is fine for communication with user space, but inside
the kernel itself we like something that is smaller and faster,
like

#define __mkdev(major, minor)  (((major) << KDEV_MINOR_BITS) + (minor))

So inside the kernel we must use kdev_t where user space
uses dev_t. Now both are arithmetic, but the bits are packed
differently.

Now you understand why I would like to remove the MKDEV
that you have in every call of blk_register_region.

Andries