No problem as long as long somebody cares.
That part stuff needs treatment as well is obvious if one looks at the
extensive allocation fallback chains I have in my small sand pille...
Would you dare to keep the following botch in mind as well please:
/*
* Returns the (struct ata_device *) for a given device number. Return
* NULL if the given device number does not match any present drives.
*/
struct ata_device *get_info_ptr(kdev_t i_rdev)
{
unsigned int major = major(i_rdev);
int h;
for (h = 0; h < MAX_HWIFS; ++h) {
struct ata_channel *ch = &ide_hwifs[h];
if (ch->present && major == ch->major) {
int unit = DEVICE_NR(i_rdev);
if (unit < MAX_DRIVES) {
struct ata_device *drive = &ch->drives[unit];
if (drive->present)
return drive;
}
break;
}
}
return NULL;
}
This get's feed to the revalidate method.
struct block_device_operations ide_fops[] = {{
.owner = THIS_MODULE,
.open = ide_open,
.release = ide_release,
.ioctl = ata_ioctl,
.check_media_change = ide_check_media_change,
.revalidate = ata_revalidate
}};
and the following ide_xlate_1024(kdev_t i_rdev botch.
I would love to go the bdev way there too :-).
But then please keep in mind that the georgeous random number
device is using the major number of a device all over the kernel...
and it's feeding the following ugly global array:
void add_blkdev_randomness(int major)
{
if (major >= MAX_BLKDEV)
return;
if (blkdev_timer_state[major] == 0) {
rand_initialize_blkdev(major, GFP_ATOMIC);
if (blkdev_timer_state[major] == 0)
return;
}
add_timer_randomness(blkdev_timer_state[major], 0x200+major);
}
Which should of course look more like:
void add_blkdev_randomness(struct block_device *ptr)
{
add_timer_randomness(((unsigned long) ptr) %
SOME_REASONABLE_VALUE, 0x200);
}
Simple couldn't resist:
1. Enabled devfs... system printed far too long
incomprehensive device names and didn't reboot.
2. I disabled automatic devfs mount... system didn't find root part either.
The only single expirence in my life, where I thought that naming disks
C: D: E: Z: isn't the worst thing that can happen.
I went curious and looked there... and *cry*.
-
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/