Alexander Viro wrote:
>
> On Fri, 31 Mar 2000, Jeff V. Merkey wrote:
>
> > This is nice to know, but it's not much help. Is there a cleaner way?
> > The simplest would be to allow me to scan the blkdev structure. I've
> > also noticed that in the cdrom drivers call ioctl_by_bdev() which would
> > be perfect to use, expect I cannot get a valid block_device * structure
> > because some of the functions are static.
> >
> > What's the best method?
>
> If you want the stuff on devices served by already loaded drivers (and
> main kernel) - look through the gendisk_head list. However, I think that
> scanning for something that looks like your data is both unsafe and rude -
> somebody might just back one of the partitions up on another disk. With
> obvious results. I would rather have the set as a config option, quite
> probably with the procfs file to pass it through
This is an excellent suggestion. I don't like the idea of grepping
through memory either. How about a very simple api in block_dev.c to
simply return whether a device is present, and whether it's a CDROM,
HDD< or Tape Device. I could code it up today. I have found that if
getblk() is called with a non-existent device, rather than return an
error, it generates a Kernel Panic.
how about:
struct blkdev_info blkdev_info {
{
int changeLinePresent;
int DeviceType;
};
int blkdev_info(kdev_t dev, &blkdev_info)
{
/*** run around and peek and poke at the gen disk heads and the
blkdev table by dev # ****/
switch (what)
{
CDROM:
blkdev_info.changeLinePresent = TRUE;
blkdev_info.DeviceType = CDROM;
return 0; // found it!
HDD:
blkdev_info.changeLinePresent = TRUE; // might be a Jaz Disk
or something.
blkdev_info.DeviceType = HDD;
return 0; // found it!
TAPE:
blkdev_info.changeLinePresent = TRUE;
blkdev_info.DeviceType = TAPE;
return 0; // found it!
default:
return -ENODEV;
}
return -1;
}
Something this simple would save my bacon -- I just need to know the
device is there and what it is prior to attempting calls to getblk or
ll_rw_block.
Very Truly Youts,
Jeff
(so that the set could be
> figured out in userland). YMMV, but pushing the code into kernel is always
> a bad idea.
What do you mean by "pushing the code into kernel"?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:29 EST