Re: More on bigger kdev_t

Andries.Brouwer@cwi.nl
Sat, 9 Oct 1999 21:20:04 +0200 (MET DST)


From sfrost@snowman.net Sat Oct 9 20:36:22 1999

On Sat, 9 Oct 1999 Andries.Brouwer@cwi.nl wrote:

> By the way, the majorstruct also has a field pointing to a function
> with a kdev_t argument that returns the name of the device,
> to be used in error messages.

Just a thought (Havn't gone back to read the other things yet,
but this caught my eye), wouldn't it make more sense to have either
both majorstruct and minorstruct have the name of the device, or just
minorstruct (Assuming it knows what majorstruct it belongs to)? My
feeling on this mainly is that you want to know EXACTLY what device
failed when a failure occurs.

Read carefully: the majorstruct also has a field pointing to a
function with a kdev_t argument that returns the name of the device.

In C terms:

struct major_struct {
unsigned int major;
char * (* namefn)(kdev_t dev);
...
};

If something is wrong, the function knows what device we are
talking about, it got the device as an argument.

Example: From glances at my /dev/sd* it looks like SCSI HDs
belong to major 8, then /dev/sda* is 0-15, /dev/sdb* is 16-31, and so
on. When I get an error, I'd want more info than just some SCSI HD
died, if possible.

So, you use

char *
sdnamefn(kdev_t dev) {
static char sdname[32];
int m = (dev->minor & 0xf);
char c = 'a' + (dev->minor >> 4);
if (!m)
sprintf(sdname, "sd%c", c);
else
sprintf(sdname, "sd%c%d", c, m);
return sdname;
}

or something in that style in case you like the sda7 terminology,
or something else in case you like to know controller and SCSI ID
and partition number.

You see - you get arbitrarily complicated names, dynamically
generated, and they cost you only 4 bytes per major - much
better than when the struct would contain its own name.

Andries

-
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/