Hi!
> >>download & install alsalib
> >>download & install alsautils
> >>create 1007 nodes in /dev
>
> I really hope you meant permission 1007 nodes, not 1007 nodes! I'm
> checking right now, and if the latter is the case, I'm going to
> uninstall alsa, even if that means my
Pavel Machek wrote:
download & install alsalib
download & install alsautils
create 1007 nodes in /dev
I really hope you meant permission 1007 nodes, not 1007 nodes! I'm
checking right now, and if the latter is the case, I'm going to
uninstall alsa, even if that
Hi!
> So... in dsp, if I wanted to record sound, I did
>
> cat /dev/dsp > /tmp/foo; cat /tmp/foo > /dev/dsp
>
> If that worked, I had usable sound system, and if it broke, I knew it
> is kernel fault.
>
> With alsa it is
>
> download & install alsalib
> download & install
Hi!
> > > >I think the sound example to the right really shows it.
> > > >/dev/dsp has a
> > > >consistent ABI on a ton of systems. The API below it,
> > > >varies. Linux got
> > > >file_operations and ALSA. Solaris/BSD may have its
> > > >vnode-and-so-on-functions and some sort of OSS.
> > >
Hi!
I think the sound example to the right really shows it.
/dev/dsp has a
consistent ABI on a ton of systems. The API below it,
varies. Linux got
file_operations and ALSA. Solaris/BSD may have its
vnode-and-so-on-functions and some sort of OSS.
I think this is a poor
Hi!
So... in dsp, if I wanted to record sound, I did
cat /dev/dsp /tmp/foo; cat /tmp/foo /dev/dsp
If that worked, I had usable sound system, and if it broke, I knew it
is kernel fault.
With alsa it is
download install alsalib
download install alsautils
Pavel Machek wrote:
download install alsalib
download install alsautils
create 1007 nodes in /dev
I really hope you meant permission 1007 nodes, not 1007 nodes! I'm
checking right now, and if the latter is the case, I'm going to
uninstall alsa, even if that means
Hi!
download install alsalib
download install alsautils
create 1007 nodes in /dev
I really hope you meant permission 1007 nodes, not 1007 nodes! I'm
checking right now, and if the latter is the case, I'm going to
uninstall alsa, even if that means my computer will forever
On Wed, 14 Mar 2007, Pavel Machek wrote:
> Hi!
>
> > >I think the sound example to the right really shows it.
> > >/dev/dsp has a
> > >consistent ABI on a ton of systems. The API below it,
> > >varies. Linux got
> > >file_operations and ALSA. Solaris/BSD may have its
> >
Hi!
> >I think the sound example to the right really shows it.
> >/dev/dsp has a
> >consistent ABI on a ton of systems. The API below it,
> >varies. Linux got
> >file_operations and ALSA. Solaris/BSD may have its
> >vnode-and-so-on-functions and some sort of OSS.
>
> I think this is a poor
Hi!
I think the sound example to the right really shows it.
/dev/dsp has a
consistent ABI on a ton of systems. The API below it,
varies. Linux got
file_operations and ALSA. Solaris/BSD may have its
vnode-and-so-on-functions and some sort of OSS.
I think this is a poor example as
On Wed, 14 Mar 2007, Pavel Machek wrote:
Hi!
I think the sound example to the right really shows it.
/dev/dsp has a
consistent ABI on a ton of systems. The API below it,
varies. Linux got
file_operations and ALSA. Solaris/BSD may have its
vnode-and-so-on-functions and some sort
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> The important part is that there's more to the story than just pv_ops.
> If you wanted to make such a change, then you'd need to refactor the
> i386 support code to add a vma->paging helper layer. That layer would
> be available for any
Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
[...] If that is the case then my ABI worries would indeed be wrong
and i'd owe Zach a big fat apology [and more] for my flames ;-)
that apology i very much owe to Zach no matter what the outcome of the
discussion. Zach,
Ingo Molnar wrote:
ok, sure, how about the one i mentioned: long-term i'd like to have a
paravirt model where the guest does not store /any/ page tables - all
paging is managed by the hypervisor. The guest has a vma tree, but
otherwise it does not process pagefaults, has no concept of a pte
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> [...] If that is the case then my ABI worries would indeed be wrong
> and i'd owe Zach a big fat apology [and more] for my flames ;-)
that apology i very much owe to Zach no matter what the outcome of the
discussion. Zach, some of my mindless
* Chris Wright <[EMAIL PROTECTED]> wrote:
> > ok, sure, how about the one i mentioned: long-term i'd like to have
> > a paravirt model where the guest does not store /any/ page tables -
> > all paging is managed by the hypervisor. The guest has a vma tree,
> > but otherwise it does not
Linus Torvalds wrote:
but ... maybe because VMI is so lowlevel and covers /all/ of x86 today,
it will always be able to emulate whatever different concept we can come
up with? Do we really know this absolutely sure?
"For sure"? Absolutely not. But since any new interfaces we come up with
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > but ... maybe because VMI is so lowlevel and covers /all/ of x86
> > today, it will always be able to emulate whatever different concept
> > we can come up with? Do we really know this absolutely sure?
>
> "For sure"? Absolutely not. But since
On 3/9/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
I think the sound example to the right really shows it. /dev/dsp has a
consistent ABI on a ton of systems. The API below it, varies. Linux got
file_operations and ALSA. Solaris/BSD may have its
vnode-and-so-on-functions and some sort of OSS.
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> * Chris Wright <[EMAIL PROTECTED]> wrote:
> > i'm not really one to argue on behalf of VMI, but i don't think it's
> > as dire make it out. [...]
>
> hey, that's what i thought when i helped do the vDSO, until i got
> slapped with cold reality called
Ingo Molnar wrote:
> ok, sure, how about the one i mentioned: long-term i'd like to have a
> paravirt model where the guest does not store /any/ page tables - all
> paging is managed by the hypervisor. The guest has a vma tree, but
> otherwise it does not process pagefaults, has no concept of a
Ingo Molnar wrote:
> yep. That's precisely my worry. And it doesnt have to be a 'great' thing
> - just any random small change in the kernel that makes sense: what is
> the likelyhood that it cannot be implemented, no matter what amount of
> insight, paravirt_ops + hyper-ABI emulation hackery,
* Chris Wright <[EMAIL PROTECTED]> wrote:
> * Ingo Molnar ([EMAIL PROTECTED]) wrote:
> > i am worried whether /any/ future change to the upstream kernel's design
> > can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i
> > mean truly any. And whether that can be done is not
On Fri, 9 Mar 2007, Ingo Molnar wrote:
>
> hm. So your point is that VMI is in essence a Turing machine (a
> near-complete one)? No matter what redesign we do on the Linux side, the
> VMI paravirt_ops will always be able to adopt to it?
No, I don't think it's turing-complete ;)
But since it
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Now it may be that you've got a change that's absolutely great for
> everyone, and the only blocker is that the FoobieVisor can't deal with
> it. OK, great, then you'd have a point.
yep. That's precisely my worry. And it doesnt have to be a
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> i am worried whether /any/ future change to the upstream kernel's design
> can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i
> mean truly any. And whether that can be done is not a function of the
> flexibility of paravirt_ops,
Ingo Molnar wrote:
> i am worried whether /any/ future change to the upstream kernel's design
> can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i
> mean truly any. And whether that can be done is not a function of the
> flexibility of paravirt_ops, it's a function of the
* Chris Wright <[EMAIL PROTECTED]> wrote:
> * Ingo Molnar ([EMAIL PROTECTED]) wrote:
> > ( if there is no backwards compatibility promise then i have zero
> > complaints: then paravirt_ops + the hypercall just becomes another API
> > internal to Linux that we can improve at will. But that is
Ingo Molnar wrote:
> but ... maybe because VMI is so lowlevel and covers /all/ of x86 today,
> it will always be able to emulate whatever different concept we can come
> up with? Do we really know this absolutely sure?
>
Why don't you make a specific proposal, and we'll work out the details.
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> If we change paravirt_ops to be higher-level ops (as we should), yes,
> the paravirt->VMI layer needs to be extended to have the
> "higher->lower" translation. But at no point did we break the
> hypervisor.
hm. So your point is that VMI is in
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> ( if there is no backwards compatibility promise then i have zero
> complaints: then paravirt_ops + the hypercall just becomes another API
> internal to Linux that we can improve at will. But that is not
> realistic: if we provide CONFIG_VMI today,
On Fri, 9 Mar 2007, Ingo Molnar wrote:
>
> _new kernel must not break on an older hypervisor_
Total red herring. AGAIN.
The paravirt_ops isn't a 1:1 hypervisor ABI.
If we change paravirt_ops to be higher-level ops (as we should), yes, the
paravirt->VMI layer needs to be extended to have
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> So please
>
> - point out things that are badly done. [...]
the thing badly done is fundamental and it trumps any other small
technological detail complaint i have, because it affects the
development and maintainance model: to promise backwards
Ingo Molnar wrote:
> Once this thing is released upstream, it creates a new compatibility
> rule:
>
> _new kernel must not break on an older hypervisor_
>
Yes, that's important. (It's perhaps more important that a new
hypervisor not break an old kernel, but that's 100% the hypervisor's
Hello,
On Mar 9 2007 20:24, Ingo Molnar wrote:
>* Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>>On Fri, 9 Mar 2007, Ingo Molnar wrote:
>>>
>>> yes - but we already support the raw hardware ABI, in the native
>>> kernel.
>>
>> Why do you continue to call paravirt an ABI?
>> We got over that.
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Similarly, maybe the VMI ABI doesn't allow for something that the
> kernel wants to do efficiently. Big deal. What relevance does that
> have to do with anything, except the fact that if true, the VMWare
> people are screwed? It's *their* problem.
On Fri, 9 Mar 2007, Ingo Molnar wrote:
>
> Unfortunately i still dont see where i'm wrong, and i'm really trying to
> understand your argument. Is your argument that as long as an ABI (VMI)
> is never directly used but only used via wrapper functions
> (paravirt_ops)
No.
My argument is
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Fri, 9 Mar 2007, Ingo Molnar wrote:
> >
> > yes - but we already support the raw hardware ABI, in the native
> > kernel.
>
> Why do you continue to call paravirt an ABI?
>
> We got over that. It's not. It's an API.
>
> VMI is an ABI.
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> i claim that when the 'API cut' is done at the right level then no more
> than say 100 hooks would be needed - with virtually zero kernel size
> increase. We've got all the right highlevel abstractions: genirq, gtod,
> clockevents. Whatever is missing
On Friday 09 March 2007 19:02, Ingo Molnar wrote:
> _1463_ hooks, spread out all around the x86 arch.
They are not all different hooks though, just many call site of the same.
Also most of them are well defined to just match what the instructions
do.
paravirt_ops has under hundred entries right
On Fri, 9 Mar 2007, Ingo Molnar wrote:
>
> yes - but we already support the raw hardware ABI, in the native kernel.
Why do you continue to call paravirt an ABI?
We got over that. It's not. It's an API.
VMI is an ABI.
As long as you try to confuse the two, there's no point to the discussion.
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > Sure, that's clean, From that perspective the apic is a bunch of
> > registers backed by a state machine or something.
>
> I think you could do much worse than just decide to pick the
> IO-APIC/lapic as your "virtual interrupt controller model".
* Linus Torvalds [EMAIL PROTECTED] wrote:
Sure, that's clean, From that perspective the apic is a bunch of
registers backed by a state machine or something.
I think you could do much worse than just decide to pick the
IO-APIC/lapic as your virtual interrupt controller model. So I do
On Fri, 9 Mar 2007, Ingo Molnar wrote:
yes - but we already support the raw hardware ABI, in the native kernel.
Why do you continue to call paravirt an ABI?
We got over that. It's not. It's an API.
VMI is an ABI.
As long as you try to confuse the two, there's no point to the discussion.
On Friday 09 March 2007 19:02, Ingo Molnar wrote:
_1463_ hooks, spread out all around the x86 arch.
They are not all different hooks though, just many call site of the same.
Also most of them are well defined to just match what the instructions
do.
paravirt_ops has under hundred entries right
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
i claim that when the 'API cut' is done at the right level then no more
than say 100 hooks would be needed - with virtually zero kernel size
increase. We've got all the right highlevel abstractions: genirq, gtod,
clockevents. Whatever is missing at
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 9 Mar 2007, Ingo Molnar wrote:
yes - but we already support the raw hardware ABI, in the native
kernel.
Why do you continue to call paravirt an ABI?
We got over that. It's not. It's an API.
VMI is an ABI.
Unfortunately i still
On Fri, 9 Mar 2007, Ingo Molnar wrote:
Unfortunately i still dont see where i'm wrong, and i'm really trying to
understand your argument. Is your argument that as long as an ABI (VMI)
is never directly used but only used via wrapper functions
(paravirt_ops)
No.
My argument is utternly
* Linus Torvalds [EMAIL PROTECTED] wrote:
Similarly, maybe the VMI ABI doesn't allow for something that the
kernel wants to do efficiently. Big deal. What relevance does that
have to do with anything, except the fact that if true, the VMWare
people are screwed? It's *their* problem.
i
* Linus Torvalds [EMAIL PROTECTED] wrote:
So please
- point out things that are badly done. [...]
the thing badly done is fundamental and it trumps any other small
technological detail complaint i have, because it affects the
development and maintainance model: to promise backwards
Ingo Molnar wrote:
Once this thing is released upstream, it creates a new compatibility
rule:
_new kernel must not break on an older hypervisor_
Yes, that's important. (It's perhaps more important that a new
hypervisor not break an old kernel, but that's 100% the hypervisor's
Hello,
On Mar 9 2007 20:24, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 9 Mar 2007, Ingo Molnar wrote:
yes - but we already support the raw hardware ABI, in the native
kernel.
Why do you continue to call paravirt an ABI?
We got over that. It's not. It's an API.
On Fri, 9 Mar 2007, Ingo Molnar wrote:
_new kernel must not break on an older hypervisor_
Total red herring. AGAIN.
The paravirt_ops isn't a 1:1 hypervisor ABI.
If we change paravirt_ops to be higher-level ops (as we should), yes, the
paravirt-VMI layer needs to be extended to have the
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
( if there is no backwards compatibility promise then i have zero
complaints: then paravirt_ops + the hypercall just becomes another API
internal to Linux that we can improve at will. But that is not
realistic: if we provide CONFIG_VMI today,
* Linus Torvalds [EMAIL PROTECTED] wrote:
If we change paravirt_ops to be higher-level ops (as we should), yes,
the paravirt-VMI layer needs to be extended to have the
higher-lower translation. But at no point did we break the
hypervisor.
hm. So your point is that VMI is in essence a
Ingo Molnar wrote:
but ... maybe because VMI is so lowlevel and covers /all/ of x86 today,
it will always be able to emulate whatever different concept we can come
up with? Do we really know this absolutely sure?
Why don't you make a specific proposal, and we'll work out the details.
* Chris Wright [EMAIL PROTECTED] wrote:
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
( if there is no backwards compatibility promise then i have zero
complaints: then paravirt_ops + the hypercall just becomes another API
internal to Linux that we can improve at will. But that is not
Ingo Molnar wrote:
i am worried whether /any/ future change to the upstream kernel's design
can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i
mean truly any. And whether that can be done is not a function of the
flexibility of paravirt_ops, it's a function of the
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
i am worried whether /any/ future change to the upstream kernel's design
can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i
mean truly any. And whether that can be done is not a function of the
flexibility of paravirt_ops, it's
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Now it may be that you've got a change that's absolutely great for
everyone, and the only blocker is that the FoobieVisor can't deal with
it. OK, great, then you'd have a point.
yep. That's precisely my worry. And it doesnt have to be a
* Chris Wright [EMAIL PROTECTED] wrote:
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
i am worried whether /any/ future change to the upstream kernel's design
can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i
mean truly any. And whether that can be done is not a
On Fri, 9 Mar 2007, Ingo Molnar wrote:
hm. So your point is that VMI is in essence a Turing machine (a
near-complete one)? No matter what redesign we do on the Linux side, the
VMI paravirt_ops will always be able to adopt to it?
No, I don't think it's turing-complete ;)
But since it
Ingo Molnar wrote:
yep. That's precisely my worry. And it doesnt have to be a 'great' thing
- just any random small change in the kernel that makes sense: what is
the likelyhood that it cannot be implemented, no matter what amount of
insight, paravirt_ops + hyper-ABI emulation hackery, for
Ingo Molnar wrote:
ok, sure, how about the one i mentioned: long-term i'd like to have a
paravirt model where the guest does not store /any/ page tables - all
paging is managed by the hypervisor. The guest has a vma tree, but
otherwise it does not process pagefaults, has no concept of a pte
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Chris Wright [EMAIL PROTECTED] wrote:
i'm not really one to argue on behalf of VMI, but i don't think it's
as dire make it out. [...]
hey, that's what i thought when i helped do the vDSO, until i got
slapped with cold reality called
On 3/9/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
I think the sound example to the right really shows it. /dev/dsp has a
consistent ABI on a ton of systems. The API below it, varies. Linux got
file_operations and ALSA. Solaris/BSD may have its
vnode-and-so-on-functions and some sort of OSS.
I
* Linus Torvalds [EMAIL PROTECTED] wrote:
but ... maybe because VMI is so lowlevel and covers /all/ of x86
today, it will always be able to emulate whatever different concept
we can come up with? Do we really know this absolutely sure?
For sure? Absolutely not. But since any new
Linus Torvalds wrote:
but ... maybe because VMI is so lowlevel and covers /all/ of x86 today,
it will always be able to emulate whatever different concept we can come
up with? Do we really know this absolutely sure?
For sure? Absolutely not. But since any new interfaces we come up with
* Chris Wright [EMAIL PROTECTED] wrote:
ok, sure, how about the one i mentioned: long-term i'd like to have
a paravirt model where the guest does not store /any/ page tables -
all paging is managed by the hypervisor. The guest has a vma tree,
but otherwise it does not process
* Ingo Molnar [EMAIL PROTECTED] wrote:
[...] If that is the case then my ABI worries would indeed be wrong
and i'd owe Zach a big fat apology [and more] for my flames ;-)
that apology i very much owe to Zach no matter what the outcome of the
discussion. Zach, some of my mindless
Ingo Molnar wrote:
ok, sure, how about the one i mentioned: long-term i'd like to have a
paravirt model where the guest does not store /any/ page tables - all
paging is managed by the hypervisor. The guest has a vma tree, but
otherwise it does not process pagefaults, has no concept of a pte
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
[...] If that is the case then my ABI worries would indeed be wrong
and i'd owe Zach a big fat apology [and more] for my flames ;-)
that apology i very much owe to Zach no matter what the outcome of the
discussion. Zach, some
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
The important part is that there's more to the story than just pv_ops.
If you wanted to make such a change, then you'd need to refactor the
i386 support code to add a vma-paging helper layer. That layer would
be available for any pv_ops
74 matches
Mail list logo
