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. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
