This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Wed May 29 04:52:26 2024 Received: from entropy.muc.muohio.edu (IDENT:root@entropy.muc.muohio.edu [134.53.213.10]) by herbie.ucs.indiana.edu (8.9.3/8.9.3) with ESMTP id WAA18004 for ; Wed, 11 Aug 1999 22:50:41 -0500 (EST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by entropy.muc.muohio.edu (8.8.7/8.8.7) with ESMTP id XAA15682; Wed, 11 Aug 1999 23:45:19 -0400 Received: by vger.rutgers.edu via listexpand id ; Mon, 9 Aug 1999 19:21:01 -0400 Received: by vger.rutgers.edu id ; Mon, 9 Aug 1999 19:10:02 -0400 Received: from neon-best.transmeta.com ([206.184.214.10]:25941 "EHLO neon.transmeta.com") by vger.rutgers.edu with ESMTP id ; Mon, 9 Aug 1999 19:03:10 -0400 Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id OAA08087; Mon, 9 Aug 1999 14:44:58 -0700 Received: from transmeta.com (hpa@cesium.transmeta.com [10.1.2.55]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id OAA00437; Mon, 9 Aug 1999 14:44:58 -0700 (PDT) Message-Id: <37AF4BDA.F14A3C5B@transmeta.com> Date: Mon, 09 Aug 1999 14:44:58 -0700 From: "H. Peter Anvin" Organization: Transmeta Corporation X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.2.7 i686) X-Accept-Language: sv, en Mime-Version: 1.0 To: Werner Almesberger Cc: linux-kernel@vger.rutgers.edu Subject: Re: Kernels > 1M References: <199908092051.WAA22254@lrcsun15.epfl.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu X-Orcpt: rfc822;linux-kernel-outgoing-dig Werner Almesberger wrote: > > So the main problems with not having access to the BIOS are > 1) "second stage" kernel needs to be updated more frequently, i.e. > whenever substantial hardware changes occur (unless it has > already access to a suitable driver, of course) > 2) extending the mechanism to boot an arbitrary other OS is > probably not feasible > > 1) just makes an existing dependency a bit more explicit. 2) is a > pity, but isn't any worse than what we have today. > Well, the thing is that if you don't have access to the BIOS anyhow, then you're really down to the stuff you can do out of initrd anyhow (except select the kernel itself, but I don't really know how useful that capability is, except on architectures like ARM/Netwinder where there is a flash ROM big enough to hold the initial booting kernel and that's simply how it boots... now one may very well see that as big enough an advantage to generalize these across all architectures.) Either way, what I'm trying to accomplish with lbcon is different -- it's a tool for bootstrapping the initrd and select boot options (including other operating systems); and non-driver (i.e. BIOS) access to disks is pretty much a requirement for that, I'm afraid, since it's going to manipulate the very disk drivers involved. -hpa  -- at work, in private! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/