Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751944AbbD3ASj (ORCPT ); Wed, 29 Apr 2015 20:18:39 -0400 Received: from mail.lang.hm ([64.81.33.126]:46061 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751794AbbD3ASh (ORCPT ); Wed, 29 Apr 2015 20:18:37 -0400 Date: Wed, 29 Apr 2015 17:18:28 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Dave Airlie cc: "Theodore Ts'o" , John Stoffel , Harald Hoyer , Richard Weinberger , "linux-kernel@vger.kernel.org" Subject: Re: [GIT PULL] kdbus for 4.1-rc1 In-Reply-To: Message-ID: References: <20150428171840.GB11351@thunk.org> <21824.5086.446831.189915@quad.stoffel.home> <5540D2F9.2010704@redhat.com> <5540DEEB.2060405@redhat.com> <21825.1619.257083.696748@quad.stoffel.home> <20150429224954.GC12374@thunk.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2414 Lines: 56 On Thu, 30 Apr 2015, Dave Airlie wrote: > On 30 April 2015 at 10:05, David Lang wrote: >> On Wed, 29 Apr 2015, Theodore Ts'o wrote: >> >>> On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote: >>>> >>>> If your customers wnat this feature, you're more than welcome to fork >>>> the kernel and support it yourself. Oh wait... Redhat does that >>>> already. So what's the problem? Just put it into RHEL (which I use >>>> I admit, along with Debian/Mint) and be done with it. >>> >>> >>> Harald, >>> >>> If you make the RHEL initramfs harder to debug in the field, I will >>> await the time when some Red Hat field engineers will need to do the >>> same sort of thing I have had to do in the field, and be amused when >>> they want to shake you very warmly by the throat. :-) >>> >>> Seriously, keep things as simple as possible in the initramfs; don't >>> use complicated bus protocols; that way lies madness. Enterprise >>> systems aren't constantly booting (or they shouldn't be, if your >>> kernels are sufficiently reliable :-), so trying to optimize for an >>> extra 2 or 3 seconds worth of boot time really, REALLY isn't worth it. >> >> >> I've had Enterprise systems where I could hit power on two boxes, and finish >> the OS install on one before the other has even finished POST and look for >> the boot media. I did this 5 years ago, before the "let's speed up boot" >> push started. >> >> Admittedly, this wasn't a stock distro boot/install, it was my own optimized >> one, but it also wasn't as optimized and automated as it could have been >> (several points where the installer needed to pick items from a menu and >> enter values) >> > > You guys might have missed this new industry trend, I think they call > it virtualisation, > > I hear it's going to be big, you might want to look into it. So what do you run your virtual machines on? you still have to put an OS on the hardware to support your VMs. Virtualization doesn't eliminate servers (as much as some cloud advocates like to claim it does) And virtualization has overhead, sometimes very significant overhead, so it's not always the right answer. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/