Re: Accessing disks via their serial numbers.

In message: <20060624174331.GB2134@xxxxxxxxxxxxxxxxx>
Pawel Jakub Dawidek <pjd@xxxxxxxxxxx> writes:
: I'd like to extend glabel(8) to create providers related to disks based
: on their serial numbers and everntually driver name.
: For example disk ad0 could also be accessed via /dev/disk/ata/3JX0LMGA
: (/dev/disk/<driver>/<serial> or /dev/disk/<serial>).

/dev/disk/ad/3JX0LMGA or /dev/disk/da/3JX0LMGA is the only thing
you'll be able to do. There's no mapping from the dev_t -> device_t,
so you have no way of knowing what the parent of the disk's dev_t.
All the I/O in the system is done with dev_t's.

Also, the cam system doesn't hook into the newbus system due to when
it was authored. There's been some resistance to moving the scsi
devices into the device_t tree, like all other storage devices. This
is part of the problem indoing thinging completely generically.

: I want to discuss mechanism for obtaining such informations.
: Currently, when disk(9) KPI is used, BIO_GETATTR requests are not passed
: down to the disks. We can eventually change this, but probably use
: additional method (not d_strategy).
: We can also not pass enitre bio structure, but only attribute name and
: buffer for the data.
:
: This is also good time to think of other informations we would like to
: export using such mechanism, so we know it will be flexible enough to
: handle them.

If all the dev_t's had a device_t, then we could hang this information
off of devd. It could create whatever links you wanted when the
device appeared, and remove them when it disappeared. There'd really
be no need to have geom involved at all :-).

: It could be eventually useful to be able to ask the disk which
: attributes it has, so we can fetch them in a loop. With BIO_GETATTR we
: don't know which attributes provider can return.

device_t's already have a number of bundles of attributes. It would
seem a shame to reinvent another mechnamism.

: Comments, ideas?

Warner
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages