All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	chaowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Subject: Re: [patch v2 2/3] Add for_each_host_dev_and_slaves for device only checking
Date: Mon, 27 Aug 2012 14:57:38 +0800	[thread overview]
Message-ID: <503B1A62.4010905@redhat.com> (raw)
In-Reply-To: <20120823152631.GI12232-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On 08/23/2012 11:26 PM, Vivek Goyal wrote:

> On Thu, Aug 23, 2012 at 11:02:23AM +0800, dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org wrote:
>> For lvm, multipath, iscsi modules they do not care about the filesystem,
>> Also there could be devcie in host_devs but it does not get formated.
>>
>> For these kind of modules, use for_each_host_dev_and_slaves will be better than use
>> for_each_host_dev_fs, here add a new function to iterate the host_devs and
>> their slave devices.
>>
>> In original for_each_host_dev_fs, it will call check_block_and_slaves which
>> will return once helper function return 0, but this is not enough for kdump
>> iscsi setup. For kdump iscsi case, it need setup each slave devices so that
>> the iscsi target can be properly setuped in initramfs.


Firstly, fix myself, check_block_and_slaves is not called in
for_each_host_dev_fs. It's called when dracut.sh collect and push
host_fs_types, so because there's no enough slave devices in
host_fs_types is_iscsi will only check the target in host_fs_types.

>>
>> Thus, this patch also add new functions check_block_and_slaves_all and
>> for_each_host_dev_and_slaves_all.
> 
> I think this patch should be broken in two parts for more clarity.


Will do

> 
> - Fix the kdump iscsi issue where we don't expect to break out of the
>   loop the moment first iscsi device is found.
> 
> - Start using host_dev instead of host_dev_fs for modules which don't
>   care about fs. Also why to have host_devs[] and host_fs_types[] both.
>   Looks like host_fs_types contains both device and fs information. I
>   think that includes strings like LVM etc.
> 
>   So can we merge both into one and those modules who don't require fs
>   info will ignore it. Or, keep one data structure host_dev_fs_types, 
>   and provide two helper functions. One which provdes on $dev in $1
>   and other which provides both dev and fs as argument to the function.


Will try the host_fs_types with optional fs type like "dev|[fs]"

-- 
Thanks
Dave

  parent reply	other threads:[~2012-08-27  6:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-23  3:02 [patch v2 0/3] add --device option dyoung-H+wXaHxf7aLQT0dZR+AlfA
2012-08-23  3:02 ` [patch v2 1/3] wait host devs in base module dyoung-H+wXaHxf7aLQT0dZR+AlfA
     [not found]   ` <20120823030627.975913807-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-08-23 15:31     ` Vivek Goyal
     [not found]       ` <20120823153138.GJ12232-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-08-27  6:35         ` Dave Young
     [not found]           ` <503B1530.6060208-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-08-27 14:58             ` Vivek Goyal
2012-08-23  3:02 ` [patch v2 2/3] Add for_each_host_dev_and_slaves for device only checking dyoung-H+wXaHxf7aLQT0dZR+AlfA
     [not found]   ` <20120823030628.133563734-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-08-23 15:26     ` Vivek Goyal
     [not found]       ` <20120823152631.GI12232-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-08-27  6:57         ` Dave Young [this message]
     [not found]           ` <503B1A62.4010905-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-08-27  8:00             ` Dave Young
     [not found]               ` <503B292A.70707-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-08-27 15:03                 ` Vivek Goyal
2012-08-23  3:02 ` [patch v2 3/3] Add a dracut option --device to bring up a device in initramfs dyoung-H+wXaHxf7aLQT0dZR+AlfA

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=503B1A62.4010905@redhat.com \
    --to=dyoung-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=chaowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    /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.