Note that some time ago I have just send out a *broken* patch which was
just exatly starting from the top... it was indeed... scary.
So I *have* tryed it that way.
However I find the bottom up approach easier becouse:
1. It needs to be done anyway.
2. It does the "hard" part first.
3. As until now the changes had turned out to be quite straight.
4. It's giving me a good chance to have a look at the intrinsics and fix
them
where needed.
5. The differences in the handling between block and char devices are
resolving
themself in a quite natural way. (In fact I didn't touch anything
char-
device releated as of now.)
> Then, all old code can be used pretty much without any changes, because
> they still use MAJOR(kdev)/MINOR(kdev), and that's trivial to implement.
6. Basically at the finish I would like to see MAJOR(kdev)/MINOR(kdev)
only
beeing used once: at kernel entry. Thereafter a pointer to an
appriopriate handler
struct should do it fine. Just changing kdev_t to a struct is somehow
only a syntactical improvement IMHO.
> After that, we can migrate things one concept at a time over to just be
> included directly in the device structure - things like hardware blocks
> sizes, size of the device etc etc. The initial thing doesn't have to be
> very large at all.
Naah from the practical point of view: I have tryed it. It turned out to
be not
as smooth as it appears at first glance. The stages I will go through
are:
1. Get away from kdev_t in the block device handling.
2. Get away from kdev_t in the VFS layer.
3. Fixup whatever turn out to be neccessary in the char device handling.
4. Tara! Do the big thing and typedef struct __kdev_t kdev_t to whatever
suits our taste...
5. Privde new versions of the kernel entry points with wide major/minor
fields.
However my ideas about points 3/4/5 are not as clear (at this time),
as about what needs to get done in 1 and 2. As of now I just don't
see a big win in starting by 4 and progressing down to 1, becouse one
can't in reality use wider minor/major fields
wihout getting 1. Done in first place. Changing the type of kdev_t
would thus be only of cosmetic value... And the approach to the problem
described above is somehow giving a relatively clear way to follow.
So once again I think its easier to "catch this dog by his tail".
Instead
from the front, where he bites ;-).
--Marcin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/