>     > But you see, the present sd_index_bits[] gives no such
    >     > guarantee. In sd_detach a bit is cleared, in sd_attach
    >     > the first free bit is given out. There is no memory.
    >
    >     But the disks are probed in the same manner as last time
    >     (if the disks/controllers are not moved, crashed etc..).
    >     So we will end up getting same names.
    >
    > Oh, but if next_index is 0 in the module (or reset by the
    > init_module code), then also with index = next_index++
    > things will be the same after rmmod/insmod.
    Here is my problem..
    #insmod ips.o
      < found 10 disks>
    #insmod qla2300.o
      < found 10 disks>
    #rmmod ips.o
       <removed 10 disks>
    #insmod ips.o
      <found 10 disks - but new names>
OK, I see what you mean. I agree.
Andries
[I see that dougg wants to solve such things by properly naming,
but that is a higher level. Given a large number space an
easier solution is to give each module its own part of the
number space.]
-
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/