On Thursday 10 April 2003 04:09 pm, Andries.Brouwer@cwi.nl wrote:
> > A different way out, especially when we use 32+32, is to kill this
> > sd_index_bits[] array, and give each disk a new number: replace
> > index = find_first_zero_bit(sd_index_bits, SD_DISKS);
> > by
> > index = next_index++;
>
> I wish it is that simple. We use sd_index_bits[] since we could
> sd_detach() and then sd_attach() few disks. We will end up with
> holes, name slippage without this. We need to know what disks are
> currently being in use.
>
> It is that simple. (At least with 64-bit dev_t.)
> Look at the use of sd_index_bits[]. It is static in sd.c.
> There is the definition, the first free bit is found (and set)
> in sd_attach() to provide our disk with a number, this bit is
> cleared again in sd_detach().
>
> That is all. In other words, a mechanism to give an unused number
> to each disk for which sd_attach() is called.
>
> Now suppose we do nothing in sd_detach().
> Then we don't know which disks have disappeared. Pity.
> If the number space is infinite then
> index = next_index++;
> gives a new number each time we need one.
Yes !! I agree. I am not worried about running out them.
I am more worried about names slipping. I atleast hope
to see device names not changing by just doing
rmmod/insmod.
Thanks,
Badari
-
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/
This archive was generated by hypermail 2b29 : Tue Apr 15 2003 - 22:00:22 EST