> I try to make sure there are no assumptions about the
> size or structure of device numbers anywhere outside kdev_t.h.
> In particular I object to the use of KDEV_MINOR_BITS.
> Apart from this formal point, there is also the practical point:
> suppose 64 = 32+32 is used, so that KDEV_MINOR_BITS equals 32.
> Then LAST_MAJOR_DISKS is 2^28 and sd_index_bits would be 32 MB array.
agreed !! (I mentioned this ealier in my previous postings - sd_index_bits
> The conclusion is that the easy way out is to define MAX_NR_DISKS.
Unfortunately, MAX_NR_DISK will be dependent on KDEV_MINOR_BITS.
We can't set MAX_NR_DISKS to arbitrary value and if there are not
enought MINOR bits, it won't work. Only way to make this work is
to do dynamic major allocation and update /dev/ entries for them.
> 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);
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/