[Patch v2 3/4] store the default dump target info when default target is a separate disk

[Baoquan He]

On 03/18/14 at 04:20pm, Vivek Goyal wrote:
> On Tue, Mar 18, 2014 at 02:35:39PM +0800, Baoquan He wrote:
> > On 03/17/14 at 11:16am, Vivek Goyal wrote:
> >  
> > > > +
> > > > +        if [ "$_fstype" = "nfs" ];then
> > > > +            kdump_install_net "$_target"
> > > > +        else
> > > > +            _target=$(kdump_to_udev_name $_target)
> > > > +        fi
> > > 
> > > Ok, we seem to have this functionality to convert to persistent names
> > > both in mkdumprd as well as dracut-module-sh. How about coming up with
> > > a common function in kudmp-lib.sh and use that at both the places. This
> > > is a cleanup and can go in a separate patch.
> > 
> > Here I don't understand, could you say more or give an example?
> 
> We convert UUID/LABEL/dev to respective persistent device name. And
> use get_persistent_dev() function ultimately.
> 
> Now there are two implementations of get_persistent_dev(). One in
> mkdumprd() and other in dracut. I think mkdumprd version came from
> dracut version.
> 
> So point being, if there is any need to convert to persistent names,
> then that logic should be shared between mkdumprd and dracut-module.sh.
> 
> We should not be using two separate functions to do the converstion.
> 
> If we define common set of functions in kdump-lib.sh and use that
> at both the places, code will become simpler, easy to understand
> and less error prone.
> 
> I realize that's little more intrisive and bigger cleanup. So I will
> open a bug to keep track of this cleanup. You can take it up after
> your other changes have been committed. I don't want your changes to
> block behind this bigger change.

Dave took the oldest version of this function to mkdumprd, now Harald
has changed it several times. 

If define it in kdump-lib.sh, any change or modification to that of
dracut version will not benifit dracut-module-setup.sh any more. This is
my worry.

Thanks for creating bug to track this, I will clean up this after this
one.

> 
> Thanks
> Vivek