> Not really. I don't know whether you ever tried the experiment
> and compiled kdev_t as a pointer to a struct with two members
> namely major and minor, where the struct is allocated by MKDEV().
> Very few places break, and these places are very easy to fix.
> Stuff that is used as numbers can be forgotten quickly.
> It is not difficult at all to get a kernel up and running that has
> kdev_t a pointer type.
Ugh... When do you free them?
> > Moreover, allocation policy for these structures is a tricky beast.
>
> Yes. I entirely agree. All the rest is a mechanical action.
> (Or, more precisely, removable modules require freeing, and
> freeing requires refcounting. It is the refcounting that is
> work, more than the allocation.)
Precisely. I think that on the block side we are fairly close to
reasonable one - at least I see how to get there. Character devices
are nastier - especially with the lack of common point on ->release()
path (->f_op reassignment done by various subsystems). Once we have
that, the rest will be pretty easy (there will be a separate issue
with per-disk objects, e.g. for serialization between open() and
BLKRRPART, but that's almost independent).
However, amount of mechanical work is going to be large - especially
if ->i_rdev becomes dev_t. That means changing types of a lot of local
variables in drivers and I'd rather leave that to 2.5. It _does_ break
source compatibility, and that makes it -CURRENT material.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/