Messages in this thread | | | Date | Mon, 06 Dec 1999 23:15:36 +0100 | From | Martin Dalecki <> | Subject | Re: 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/
| |