lkml.org 
[lkml]   [2001]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:08    [W:0.068 / U:1.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site