Messages in this thread | | | Date | Sun, 20 Apr 2003 23:35:08 +0100 | From | viro@parcelfa ... | Subject | Re: [CFT] more kdev_t-ectomy |
| |
On Sun, Apr 20, 2003 at 11:58:18PM +0200, Andries.Brouwer@cwi.nl wrote:
> [Now that we are talking anyway, let me ask about something. > You wrote blk_register_region so that subregions override > superregions. At the bottom there is the full region. > Was this just a general good idea, or do you have definite > applications in mind? I ask this mostly because the hash
A lot of them. Consider, e.g., ide code. Or any other driver with subdrivers - anything that can't be just done by blind "here's device number, that's enough to know what should be loaded".
In case of ide we have regions corresponding to hwifs (== IDE cables) and each of them can carry up to two devices. We can see that 22:43 is to be handled by IDE, no problems with that. But then we get to decide whether it's ide-disk or ide-cd or ide-floppy. IDE code knows what is needed - it had probed devices already and it knows that master on that cable is a disk. So attempt to open that sucker should refer to IDE code, which, in turn, should know that we need to load a high-level driver (ide-disk.o). After that we have a normal range (64 numbers) for master. But not necessary for slave - if it is an ide-cd, we still might have no driver loaded.
We could play splitting these ranges and merging them (i.e. original range shrinks and subrange is added as the first-level one), but that gets very nasty when you try to get it right (you need to merge these suckers during cleanup, etc.)
> and that is OK for regions with constant major. > For multimajor regions a hash does not work very well, and > a tree looks better.]
Tree certainly looks better. I'd played with route cache code (after all, that's exactly the same problem), but it looked like an overkill. I'm porting genhd.c code for character devices, if that will show up in profiles we'll always be able to optimize that stuff. It is fairly isolated, so changes of lookup data structures should not affect anything else. - 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/
| |