[PATCH 2/2] kexec-tool: Append reset_devices flag to second kernel commandline

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Thu, Jan 04, 2007 at 10:51:57AM -0500, Don Zickus wrote:
> On Thu, Jan 04, 2007 at 08:59:10AM -0500, Neil Horman wrote:
> > > Hi Neil,
> > > 
> > > That solution would be very specific to RedHat. If a user on non RHEL5
> > > distro tries to use kdump then how would he handle it?
> > > 
> > I understand that, but the point I'm trying to make is that this seems like it
> > would be better to do in an initscript in general.  We've seen the need to add
> > specific commandline parameters for specific systems several times now.  Instead
> > of updating the kexec code to detect and add appropriate parameters for every
> > system out there, wouldn't it be better if each distro provided  a way for a
> > user to configure any needed additional parameters that an initscript could then
> > just pass along to the kernel using the --command-line option?
> I have to agree with Neil here.  I think part of the problem is
> kexec-tools is bursting at its britches here.  It is starting to turn into
> a real application that needs config files and init scripts.  I can see
> the maintainers and developers are trying hard to avoid it by adding in
> hacks like this.  But the bottom line is, if kexec-tools is to be done
> right you guys are going to have to create an infrastructure for it.  
> I know it's the last thing a bunch of kernel developers want to do, but I
> think its the right way.  You can probably even follow the kernel model of
> of creating a directory in the git repo called scripts/ and put the init
> and config scripts in there.  Also you could probably add some rpm
> packaging to a Makefile to bundle it up and install it correctly.
> Just some thoughts.
> > 
> > > Another option can be that we specify this thing in kdump documentation so
> > > that a user can add this parameter additionally along with maxcpus=1 and
> > > irqpoll. Then respective distros can choose to automate this whole process
> > > and add append reset_devices through init scripts.
> > > 
> > I absolutely agree.  I think this is the way to go forward.  It keeps us from
> > having to update kexec binaries when someone wants/needs new command line
> > parameters (for which there may be countless combinations of out in the field).
> > Make the distros provide a method for leveraging the already existing
> > functionality of kexec instead (in this case --command-line).  Its less
> > confusing and more flexible IMO.
> I agree. 

Taking a step back, when exactly is reset_devices needed?

While I agree with the idea that fundamentally distros should
know what arguments to pass to kexec-tools at what times, if it is
an option that for instance always makes sense on i386, then 
it seems like it is a clean solution for kexec-tools itself to add it
as in that case it certainly wouldn't be a distribution specific 
choice, nor would it be something terribly difficult to detect.

If the argument is that kexec-tools needs to be kept flexible,
and for that reason it needs configuration files and the like,
then I am all for it. But if the argument is that some of the generic
(non distribution-specific) logic needs to be written in shell scripts
rather than as part of the main application, well I'm not sure that I
understand the benefit.

  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

[Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Linux Media]     [Linux Resources]

Powered by Linux