On 8/9/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-09 at 21:07 +1000, Rusty Russell wrote:
> > From: Ronald G. Minnich <[EMAIL PROTECTED]>
> >
> > [ FC7 maps shared libraries very low, where the launcher maps guest's
> > physical memory. Quick fix is to link Launcher static,
Hi, I'm sorry, I've been stuck on other things (NFS RDMA anyone?) and
missed part of this discussion.
Is it really the case that operations on virtio devices will involve
outl/inl etc.?
Apologies in advance for my failure to pay attention.
thanks
ron
-
To unsubscribe from this list: send the li
Mitch Bradley wrote:
Request for comments.
Sorry to revive this thread, I just ran through the discussion. I'm
about 50% in agreement with the idea.
I'd like to put in my $.02 in favor of having a way to pass the OF
device tree to the kernel, in much the same way we pass stuff like
ACPI and PI
On 1/11/07, Mitch Bradley <[EMAIL PROTECTED]> wrote:
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or non-callback.
It is still being tested.
Wonderful! If the non-callback version works out, then we can greatly
widen
On 1/11/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
This works fine for just passing the device tree, but it will fail for
the next step of being able to use the firmware in the OS, and returning
sanely to the firmware.
And why is it we need to do that, presently? And how, in a virtualized
On 1/11/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
Depends. The kernel _can_ shut down OF; in that case, it
becomes responsible for passing the device tree along to
the kexec'd kernel.
so we will need the non-callback support anyway, it seems?
thanks
ron
-
To unsubscribe from this l
On 9/13/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
> Hi Andi and everyone,
>
> Wanted to get your thoughts on this patch. lguest now supports plan9
> guests which use 0x40 for system calls. We want to let the guests use
> that vector if available, but have no way to stop io_apic from
>
I pinged the person again. Hope to hear today. Sorry for delay.
On Sun, Dec 6, 2020 at 11:52 PM Sven Eckelmann wrote:
>
> On Friday, 27 November 2020 19:54:30 CET ron minnich wrote:
> > Thanks, Sven, for your patience, I will indeed try to test this next week.
>
> Any test
Tested-by: Ian Goegebuer
On Mon, Dec 7, 2020 at 7:24 AM ron minnich wrote:
>
> I pinged the person again. Hope to hear today. Sorry for delay.
>
> On Sun, Dec 6, 2020 at 11:52 PM Sven Eckelmann wrote:
> >
> > On Friday, 27 November 2020 19:54:30 CET ron minnich wrote:
It is likely we're missing something -- I am not fully checked out on
the Linux patch process and it's Ian's first patch.
Guidance appreciated.
On Mon, Jan 4, 2021 at 1:08 AM Miquel Raynal wrote:
>
> Hello Ian,
>
> Ian Goegebuer wrote on Wed, 23 Dec 2020 13:56:30
> -0800:
>
> > On Intel platfor
gt; making mtdpart= parsing impossible. Let's fix the parser to gracefully
> > handle that case: the last ':' in a partition definition sequence is
> > considered instead of the first one.
> >
> > Signed-off-by: Boris Brezillon
> > Si
I can't think
of anything better that lets us preserve current behavior and support
PCI device specifiers?
Ron
On Fri, Nov 27, 2020 at 9:06 AM Sven Eckelmann wrote:
>
> On Friday, 27 November 2020 17:32:02 CET ron minnich wrote:
> > I'm a bit worried about how tricky this star
Thanks, Sven, for your patience, I will indeed try to test this next week.
On Fri, Nov 27, 2020 at 9:35 AM Sven Eckelmann wrote:
>
> On Friday, 27 November 2020 18:16:54 CET ron minnich wrote:
> > What none of the people involved in the original patch knew was that
> > th
On Fri, Sep 5, 2014 at 1:05 PM, H. Peter Anvin wrote:
> I'm not a fan of Coreboot having invented its own nonstandard hacks, but
> I guess it is pretty much unavoidable.
I suspect this should not be architecture-dependent, since coreboot
tables work across 3 coreboot architectures at present wit
Vladimir can you point me to that patch? This sounds interesting.
ron
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://w
The other thing you ought to consider fixing:
initrd is documented as follows:
initrd= [BOOT] Specify the location of the initial ramdisk
for bootloaders only.
UEFI consumes initrd from the command line as well. As ARM servers
increasingly use UEFI, there may be situations in whi
So, let me first add, the comment can be removed as needed. Comments
offered only for clarification.
On Mon, Jun 22, 2020 at 1:40 PM Tom Rini wrote:
> But what do you mean UEFI "consumes" initrd= ?
What I mean is, there are bootloaders that will, if they see initrd=
in the command line, remove
It seems fine to me, but I did not initially object to the use of that
name anyway. hpa, what do you think?
On Fri, Jun 19, 2020 at 7:31 AM Tom Rini wrote:
>
> Most architectures have been passing the location of an initrd via the
> initrd= option since their inception. Remove the comment as it'
18 matches
Mail list logo
