> +enum {
> + VMCI_SUCCESS_QUEUEPAIR_ATTACH = 5,
> + VMCI_SUCCESS_QUEUEPAIR_CREATE = 4,
> + VMCI_SUCCESS_LAST_DETACH= 3,
> + VMCI_SUCCESS_ACCESS_GRANTED = 2,
> + VMCI_SUCCESS_ENTRY_DEAD = 1,
We've got a nice collection of Linux error codes than you, and it
> Also:
> - use C99 style initialization.
> - add missing entry in documentation for loop-control
>
> Signed-off-by: Stephen Hemminger
For the device allocation
Acked-by: Alan Cox
___
Virtualization mailing list
Virtualizat
> > ACKs, NACKs? What is happening here?
>
> I would like an Ack from Alan Cox who switched vhost-net
> to a dynamic minor in the first place, in commit
> 79907d89c397b8bc2e05b347ec94e928ea919d33.
Sorry dev...@lanana.org isn't yet back from the kernel hack incident.
> I have no desire to change the 'genericness' of sockets.. just the
> opposite - i wish to
> introduce the notion that sockets (can be) completely generic (when
> offloaded) as far as
> the guest is concerned.
I suppose my concern is that you don't want to design for a specific
offload device, yo
> Q: whay happens about in process socket syscalls in another thread ?
> Thats always been the ugly in these cases either by intercepting or by
> swapping file operations on an object.
Sorry I meant "in progress" 8)
___
Virtualization mailing list
Virtua
> The Berkeley sockets coprocessor is a virtual PCI device which has the ability
> to offload socket activity from an unmodified application at the BSD sockets
Ok I think there is an important question here. Why is this being
designed for a specific virtual interface. Unix has always had the notio
> Do not send more than 15 patches at once to the vger
> mailing lists!!!
>
> and, accordingly, I went to the trouble of setting up a GitHub
> account to host a repo from which I could issue *one* single
> PULL request email; I get a little miffed every time my
> inbox gets blasted with hundre
> Again, this is paravirtual serial device and I think it's entirely
> reasonable for people to hook up these ports in the guest directly to
> physical serial devices in the host.
virtio doesn't support all those features.
> I fail to see how this is at all relevant. This is a virtual
> machin
> We do actually want hangup and a few other of the tty specific ops.
> The only thing we really don't want is a baud rate.
So you need break, parity ... no be serious please
> This device cannot be implemented as-is in userspace because it
> depends on DMA which precludes the use of something li
> Alan, I'm not sure how many ports at a time people would want to use so
> allocating one major device for this seems OK?
We have very large minor number ranges now so one dynamic major should do
you for a while yet. Probably forever but thats always asking for a
"640K.." moment ;)
> +static ss
> Well, really fundamentally, this is just a reliable full-duplex byte
> stream, with connect and hangup notification. To me, that sounds more
> like TCP with an address family almost, but not quite AF_UNIX, but that
> case was thrown out of court long ago, so here we are.
Well the tty one has al
> This device is very much a serial port. I don't see any reason not
> to treat it like one.
Here are a few
- You don't need POSIX multi-open semantics, hangup and the like
- Seek makes sense on some kinds of fixed attributes
- TTY has a relatively large memory overhead per device
- Sysfs is wha
> The interface presented to guest userspace is of a simple char
> device, so it can be used like this:
>
> fd = open("/dev/vcon2", O_RDWR);
> ret = read(fd, buf, 100);
> ret = write(fd, string, strlen(string));
>
> Each port is to be assigned a unique function, for example, the
> fir
> - Then, are we certain that there's no case where the tty layer will
> call us with some lock held or in an atomic context ? To be honest,
> I've totally lost track of the locking rules in tty land lately so it
> might well be ok, but something to verify.
Some of the less well behaved line disc
> few minor coding style issues reported by checkpatch.pl:
checkpatch is a *guide* not some dictator of style. If it's more readable
the way it is, or it's following existing style (eg with the export
symbols in a group at the bottom) then checkpatch is best ignored.
__
> I still think it's preferable to change some drivers than everybody.
>
> AFAIK BusLogic as real hardware is pretty much dead anyways,
> so you're probably the only primary user of it anyways.
> Go wild on it!
I don't believe anyone is materially maintaining the buslogic driver and
in time its g
> out is usually a single byte. Shouldn't be very expensive
> to decode. In fact it should be roughly equivalent to your
> hypercall multiplex.
Why is a performance critical path on a paravirt kernel even using I/O
instructions and not paravirtual device drivers ?
It clearly makes sense to virtua
> Agreed. But not everyone wants to or should have to use git,
> so what are the alternatives?
Export the recent git history each release into an XML file at known
locations on the kernel web site. Wait for tools to appear
___
Virtualization mailing lis
On Fri, 10 Aug 2007 15:08:35 -0300
"Glauber de Oliveira Costa" <[EMAIL PROTECTED]> wrote:
> On 8/9/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> > > What's the EBDA actually used for? The only place which seems to use
> > > ebda_addr is in the e820 co
> What's the EBDA actually used for? The only place which seems to use
> ebda_addr is in the e820 code to avoid that area as RAM.
It belongs to the firmware.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-
On Tue, 24 Jul 2007 20:28:14 +1000
Rusty Russell <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-24 at 10:52 +0100, Alan Cox wrote:
> > > There once was a virtualization coder,
> > > Whose patches kept getting older,
> > > Each time upstream would drop,
> >
> So when you say "there's not enough poetry", next time you'll know why.
> You *really* don't want want poetry.
That isn't poetry. We'll be doing Finnish jokes next 8). I'm also not
sure that kernel documentation in rhyme is the best idea:
---
Ah look at all the laundered pages
Ah
> There once was a virtualization coder,
> Whose patches kept getting older,
> Each time upstream would drop,
> His documentation would slightly rot,
> SO APPLY MY FUCKING PATCHES OR I'LL KEEP WRITING LIMERICKS.
There once was a man they called rusty
Who patches were terribly crusty
Though his
> > Because that's really the issue: do you want a "pretty" backtrace, or do
> > you want one that is rock solid but has some crud in it.
>
> I just want an as exact backtrace as possible. I also think
> that we can make the unwinder robust enough.
Any reason you can't put the exact back trace i
24 matches
Mail list logo
