Messages in this thread |  | | Date | Thu, 11 Oct 2001 18:26:42 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: 2.4.11 loses sda9 |
| |
On Thu, 11 Oct 2001 Andries.Brouwer@cwi.nl wrote:
> 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/
|  |