From: Greg KH <greg@kroah.com>
To: lvm-devel@sistina.com, linux-kernel@vger.kernel.org
Subject: Re: [lvm-devel] [PATCH] add kobject to struct mapped_device
Date: Fri, 20 Dec 2002 09:49:52 -0800 [thread overview]
Message-ID: <20021220174952.GB12128@kroah.com> (raw)
In-Reply-To: <20021220094447.GA1169@reti>
On Fri, Dec 20, 2002 at 09:44:47AM +0000, Joe Thornber wrote:
> On Fri, Dec 20, 2002 at 12:31:50AM -0800, Greg KH wrote:
> > 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.
Yeah, it's not that bad, I'll look into it when I get to those files :)
> 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 ?).
Yes, I think this is still true. And it's also a good way to enforce
the "one value per file" rule :)
> 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.
I saw that logic. I don't think sysfs can handle poll right now, but we
could modify the last access/modify/change time when the status changes
so stat(2) can be used on the file. This is how usbfs currently
notifies userspace of changes to their files. Would this be acceptable?
> > 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.
Ok, will do.
thanks for your comments,
greg k-h
next prev parent reply other threads:[~2002-12-20 17:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-18 18:43 [PATCH] add kobject to struct mapped_device Greg KH
2002-12-18 18:53 ` [lvm-devel] " Greg KH
2002-12-19 10:55 ` Joe Thornber
2002-12-20 8:31 ` Greg KH
2002-12-20 9:44 ` Joe Thornber
2002-12-20 17:49 ` Greg KH [this message]
2002-12-30 10:57 ` Joe Thornber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021220174952.GB12128@kroah.com \
--to=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lvm-devel@sistina.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.