Re: [lvm-devel] [PATCH] add kobject to struct mapped_device

[Joe Thornber]

On Fri, Dec 20, 2002 at 12:31:50AM -0800, Greg KH wrote:
> Here's an ascii picture which probably makes more sense:
> /sys/block/
> |-- fd0
> |   |-- dev
> |   |-- range
> |   |-- size
> |   `-- stat
> |-- dm-1
> |   |-- dev
> |   |-- dm
> |   |   |-- device0 -> ../../devices/pci0/00:02.5/ide0/0.0
> |   |   |-- device1 -> ../../devices/pci0/00:02.5/ide1/1.0
> |   |   |-- status
> |   |   |-- suspend
> |   |   `-- table
> |   |-- range
> |   |-- size
> |   `-- stat
> 
> Look reasonable?

Yes, it looks promising.  Some worries:

i) The 'status' and 'table' files do not contain a single value.
Splitting it up into single values would be ungainly to say the least,
eg.

  dm
  |-- table
      |-- target1
      |   |-- sector_start
      |   |-- sector_len
      |   |-- target_type
      |   `-- target args
      |
      |-- target2
          |-- sector_start

  hmm ... maybe that's not too bad.

ii) If the table files are not split up then we have the problem that
    they can be larger than a single page, which sysfs can't handle
    (is this still true ?).

iii) We need to be able to poll on the status file so that people can
     block until there is a change of status.  eg, a snapshot uses up
     another 5% of its COW storage, a mirror completes its initial
     build, a path fails in the multipath target.

> Ok.  I can place all of the sysfs specific functions in dm.c, just like
> drivers/block/genhd.c has, or if we place struct mapped_device into
> dm.h, they can live in their own file.  Doesn't bother me either way.

Either put it in dm.c, or define some extra access functions (like
dm_suspended() and dm_kdev()) to get the information you need.  I
would prefer the latter, but we can always move things later.

- Joe