lkml.org 
[lkml]   [1999]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH for 2.3.29: block device setup cleanup.
Linus Torvalds wrote:
>
> On Mon, 6 Dec 1999, Marcin Dalecki wrote:
> >
> > I'm aimin at the whole issure from the bottom (read device handling part)
> > instead of starting by the top (kdev_t type and passing semantics).
> > This is becouse I think that the lower level stuff is just a prerequsite
> > for the second. Surely at the finish line I see too that kdev_t (or whatever
> > name we end up....) will be vanishing.
>
> Note that you don't have to start it from the bottom. In many cases it is
> _easier_ to start it from the top: make a simple "device structure" that
> in the first incarnation has nothing but (a) major/minor number and (b) a
> reference count (we need the latter to make sure that we get the dynamic
> behaviour right).

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/

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