[9fans] 8c question

[9fans] 8c question

[Tim Newsham]

Is it possible to make a zero-length type (ie. a structure or
array of zero length) in 8c?  The headers in xen3 require this
(ugh) and it cant be worked around without breaking the cross
platform features of their headers.

Tim Newsham
http://www.lava.net/~newsham/

Re: [9fans] 8c question

[Charles Forsyth]

>>it cant be worked around without breaking the cross
>>platform features of their headers.

sounds brilliantly portable to me.
what do they do?  insert 0-length padding areas
to make these structures `portable'?

Re: [9fans] 8c question

[David Leimbach]

On 7/2/05, Charles Forsyth <forsyth@terzarima.net> wrote:
> >>it cant be worked around without breaking the cross
> >>platform features of their headers.
> 
> sounds brilliantly portable to me.
> what do they do?  insert 0-length padding areas
> to make these structures `portable'?
> 
> 
Yeah, it's undefined what happens if a struct is empty in C99. Seems a
really silly thing for someone to rely on.  What are they trying to
accomplish?  The only thing I can think of is some kind of type safety
based on a tag generated for a unique "struct".  They should probably
make it wrap a void * or something.

Re: [9fans] 8c question

[Ronald G. Minnich]

On Mon, 4 Jul 2005, David Leimbach wrote:

> On 7/2/05, Charles Forsyth <forsyth@terzarima.net> wrote:
> > >>it cant be worked around without breaking the cross
> > >>platform features of their headers.
> > 
> > sounds brilliantly portable to me.
> > what do they do?  insert 0-length padding areas
> > to make these structures `portable'?
> > 
> > 
> Yeah, it's undefined what happens if a struct is empty in C99. Seems a
> really silly thing for someone to rely on.  What are they trying to
> accomplish?  The only thing I can think of is some kind of type safety
> based on a tag generated for a unique "struct".  They should probably
> make it wrap a void * or something.
> 


IIRC this is one of those deals where people do something liiek:

struct element {
	int x,y;
};

struct a {
	int numelements;
	struct elements blah[0];
};

is that it Tim? I might be wrong on this. 

It's not reliable in gcc, as we found out the hard way on the linuxbios 
project ...

ron

Re: [9fans] 8c question

[Latchesar Ionkov]

An example:

	typedef struct {
		....
		arch_vcpu_info_t arch;
	} vcpu_info_t;

For x86_32 and x86_64 arch_vcpu_info_t is defined as:

	typedef struct {
	} arch_vcpu_info_t;

    Lucho

On Mon, Jul 04, 2005 at 07:36:58PM -0700, David Leimbach said:
> On 7/2/05, Charles Forsyth <forsyth@terzarima.net> wrote:
> > >>it cant be worked around without breaking the cross
> > >>platform features of their headers.
> > 
> > sounds brilliantly portable to me.
> > what do they do?  insert 0-length padding areas
> > to make these structures `portable'?
> > 
> > 
> Yeah, it's undefined what happens if a struct is empty in C99. Seems a
> really silly thing for someone to rely on.  What are they trying to
> accomplish?  The only thing I can think of is some kind of type safety
> based on a tag generated for a unique "struct".  They should probably
> make it wrap a void * or something.

Re: [9fans] 8c question

[Ronald G. Minnich]

On Tue, 5 Jul 2005, Latchesar Ionkov wrote:

> An example:
> 
> 	typedef struct {
> 		....
> 		arch_vcpu_info_t arch;
> 	} vcpu_info_t;
> 
> For x86_32 and x86_64 arch_vcpu_info_t is defined as:
> 
> 	typedef struct {
> 	} arch_vcpu_info_t;
> 
>     Lucho

oh, wow, had not remembered this one. 

so, can we convince them to put in something like
	int nothingtoseeheremovealong;

ron

Re: [9fans] 8c question

[Tim Newsham]

> so, can we convince them to put in something like
> 	int nothingtoseeheremovealong;

I'm trying to.

> ron

Tim Newsham
http://www.lava.net/~newsham/

Re: [9fans] 8c question

[David Leimbach]

On Jul 5, 2005, at 8:27 AM, Latchesar Ionkov wrote:

> An example:
>
>     typedef struct {
>         ....
>         arch_vcpu_info_t arch;
>     } vcpu_info_t;
>
> For x86_32 and x86_64 arch_vcpu_info_t is defined as:
>
>     typedef struct {
>     } arch_vcpu_info_t;
>

That's undefined behavior by the C99 standard, as far as I can tell.

You are supposed to have a non-empty list of identifiers and types
in any given struct or union.

Definitely not good for portability.

Dave


>     Lucho
>
> On Mon, Jul 04, 2005 at 07:36:58PM -0700, David Leimbach said:
>
>> On 7/2/05, Charles Forsyth <forsyth@terzarima.net> wrote:
>>
>>>>> it cant be worked around without breaking the cross
>>>>> platform features of their headers.
>>>>>
>>>
>>> sounds brilliantly portable to me.
>>> what do they do?  insert 0-length padding areas
>>> to make these structures `portable'?
>>>
>>>
>>>
>> Yeah, it's undefined what happens if a struct is empty in C99.  
>> Seems a
>> really silly thing for someone to rely on.  What are they trying to
>> accomplish?  The only thing I can think of is some kind of type  
>> safety
>> based on a tag generated for a unique "struct".  They should probably
>> make it wrap a void * or something.
>

Re: [9fans] 8c question

[Charles Forsyth]

i don't understand.  if it's in the portability interface,
you say what arch_vcpu_info_t is, so why not
typedef int arch_vcpu_info_t;
and be done with it.  i don't see why it must be a struct
in that context.

i'd assumed (based on having looked at some xen headers
a month ago) that they'd used 0-length things to try to
get round some portability problem with `packed' structs,
but the problem seems simpler than that.

Re: [9fans] 8c question

[Ronald G. Minnich]

On Fri, 8 Jul 2005, Charles Forsyth wrote:

> i don't understand.  if it's in the portability interface, you say what
> arch_vcpu_info_t is, so why not typedef int arch_vcpu_info_t; and be
> done with it.  i don't see why it must be a struct in that context.

As I understand it, current Linux practice is to not use typedefs. So, 
that approach will not go.

ron

Re: [9fans] 8c question

[Russ Cox]

Nonsense.  There are plenty of typedefs in Linux.

tux=; pwd
/usr/src/kernel-source-2.6.5
tux=; find . -name '*.c' | xargs -n 100 grep typedef | wc
   1278    5476   79522
tux=; 

Russ

Re: [9fans] 8c question

[Ronald G. Minnich]

On Thu, 7 Jul 2005, Russ Cox wrote:

> Nonsense.  There are plenty of typedefs in Linux.

for scalar types, sure. They're all over the place. Did you look any 
deeper than the grep | wc?

What is being proposed is a typedef for something that might or might not 
be a struct, depending on architecture. I'll be interested to see if that 
flies. Go for it.

ron

Re: [9fans] 8c question

[jmk]

On Fri Jul  8 10:37:10 EDT 2005, rminnich@lanl.gov wrote:
> 
> 
> On Thu, 7 Jul 2005, Russ Cox wrote:
> 
> > Nonsense.  There are plenty of typedefs in Linux.
> 
> for scalar types, sure. They're all over the place. Did you look any 
> deeper than the grep | wc?
> 
> What is being proposed is a typedef for something that might or might not 
> be a struct, depending on architecture. I'll be interested to see if that 
> flies. Go for it.
> 
> ron

There are actually more 'struct' typedefs in the linux header files
than Russ found in the .c files:

ethel% pwd
/n/other/jmk/linux-2.6.9/include
ethel% grep 'typedef.*{' */*.h|wc 
   1351    5593   62194
ethel% 

e.g. linux/spinlock.h:

#if (__GNUC__ > 2)
  typedef struct { } spinlock_t;
  #define SPIN_LOCK_UNLOCKED (spinlock_t) { }
#else
  typedef struct { int gcc_is_buggy; } spinlock_t;
  #define SPIN_LOCK_UNLOCKED (spinlock_t) { 0 }
#endif

Re: [9fans] 8c question

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 114 bytes --]

talk about making something simple as bizarre as possible.
that include file is just amazing, quite remarkable.

[-- Attachment #2: Type: message/rfc822, Size: 3013 bytes --]

From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 8c question
Date: Fri, 8 Jul 2005 15:03:12 -0400
Message-ID: <f4e875772b165f384f8dd867dc1819b0@plan9.bell-labs.com>

On Fri Jul  8 10:37:10 EDT 2005, rminnich@lanl.gov wrote:
> 
> 
> On Thu, 7 Jul 2005, Russ Cox wrote:
> 
> > Nonsense.  There are plenty of typedefs in Linux.
> 
> for scalar types, sure. They're all over the place. Did you look any 
> deeper than the grep | wc?
> 
> What is being proposed is a typedef for something that might or might not 
> be a struct, depending on architecture. I'll be interested to see if that 
> flies. Go for it.
> 
> ron

There are actually more 'struct' typedefs in the linux header files
than Russ found in the .c files:

ethel% pwd
/n/other/jmk/linux-2.6.9/include
ethel% grep 'typedef.*{' */*.h|wc 
   1351    5593   62194
ethel% 

e.g. linux/spinlock.h:

#if (__GNUC__ > 2)
  typedef struct { } spinlock_t;
  #define SPIN_LOCK_UNLOCKED (spinlock_t) { }
#else
  typedef struct { int gcc_is_buggy; } spinlock_t;
  #define SPIN_LOCK_UNLOCKED (spinlock_t) { 0 }
#endif

Re: [9fans] 8c question

[Ronald G. Minnich]

On Fri, 8 Jul 2005 jmk@plan9.bell-labs.com wrote:

> There are actually more 'struct' typedefs in the linux header files
> than Russ found in the .c files:

yeah, maybe I should have been less terse. 

Based on past year and change of watching the infiniband mailling list
discussions, my overall belief is that something along the lines of

if you're a 386
typedef int xyz;

if you're some other arch:
typedef struct { int somestuff} xyz;

and then using that in something else, e.g. another struct or a function 
prototype, is just not going to be well received. I may well be wrong, 
some of the discussions get a little abstruse for me, and I ended up 
blowing the email thread away.

ron

Re: [9fans] 8c question

[Tim Newsham]

> i don't understand.  if it's in the portability interface,
> you say what arch_vcpu_info_t is, so why not
> typedef int arch_vcpu_info_t;
> and be done with it.  i don't see why it must be a struct
> in that context.

Typedefing it to an int would be fine, except then it will
be four bytes larger in Plan9 than it is in the Xen host.
Since this is a shared data structure, bad things will happen.

I think I might be able to get them to set it to some fixed
length size and just waste some space.  Its just a matter of
me getting time to create a patch and test it and submit it.

Tim Newsham
http://www.lava.net/~newsham/

Re: [9fans] 8c question

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 133 bytes --]

sorry, i hadn't properly understood the context in which those
declarations were used.  i'll look at them again with that in mind.

[-- Attachment #2: Type: message/rfc822, Size: 2996 bytes --]

From: Tim Newsham <newsham@lava.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] 8c question
Date: Thu, 7 Jul 2005 17:31:00 -1000 (HST)
Message-ID: <Pine.BSI.4.61.0507071729150.8592@malasada.lava.net>

> i don't understand.  if it's in the portability interface,
> you say what arch_vcpu_info_t is, so why not
> typedef int arch_vcpu_info_t;
> and be done with it.  i don't see why it must be a struct
> in that context.

Typedefing it to an int would be fine, except then it will
be four bytes larger in Plan9 than it is in the Xen host.
Since this is a shared data structure, bad things will happen.

I think I might be able to get them to set it to some fixed
length size and just waste some space.  Its just a matter of
me getting time to create a patch and test it and submit it.

Tim Newsham
http://www.lava.net/~newsham/

Re: [9fans] 8c question

[Tim Newsham]

> I think I might be able to get them to set it to some fixed
> length size and just waste some space.  Its just a matter of
> me getting time to create a patch and test it and submit it.

They went ahead and put stuff into the empty structure (useful
stuff too!) making the problem magically disappear.  We
can all sleep tight tonight.

Tim Newsham
http://www.lava.net/~newsham/

Re: [9fans] 8c question

[Charles Forsyth]

>>We can all sleep tight tonight.

not if i start to wonder about the surrounding software, when such
sloppy assumptions are made in something as important as
the interface.  i'd already thought, glancing at it months ago,
that there seemed to be rather a lot of interface, which also
made me wonder, but i'd made a mental note to revisit it
when i had more time.

Re: [9fans] 8c question

[Ronald G. Minnich]

On Sat, 9 Jul 2005, Charles Forsyth wrote:

> not if i start to wonder about the surrounding software, when such
> sloppy assumptions are made in something as important as the interface.  
> i'd already thought, glancing at it months ago, that there seemed to be
> rather a lot of interface, which also made me wonder, but i'd made a
> mental note to revisit it when i had more time.

we have been trying and failing to get the xen guys interested in 9p as 
the backbone comms for inter-domain communication in Xen, both dom0->domU 
and domU->domU. 

What we're lacking is anyone with a time to write the proof-of-concept 
implementation. I wish we could get it done, because the inter-domain 
comms in xen just keep getting more and more complex. 

It's been hard to even argue that you could use the same
open/read/write/close interface for a disk and an ethernet device. "Linux
doesn't do that ...". So we have a disk virtual device and an ethernet
virtual device that are very, very different in implementation, even
though it's basically a 2-way shared-memory fifo queue in each case. I
really think they could be the same.

ron

[9fans] Xen comms

[Tim Newsham]

> we have been trying and failing to get the xen guys interested in 9p as
> the backbone comms for inter-domain communication in Xen, both dom0->domU
> and domU->domU.

I think it would be a hard sell.  You'd still want to have something
like a shared memory queue to exchange messages but on top of
that you'd have a rather large amount of 9p machinery.

> ron

Tim Newsham
http://www.lava.net/~newsham/

Re: [9fans] Xen comms

[Eric Van Hensbergen]

On 7/10/05, Tim Newsham <newsham@lava.net> wrote:
> > we have been trying and failing to get the xen guys interested in 9p as
> > the backbone comms for inter-domain communication in Xen, both dom0->domU
> > and domU->domU.
> 
> I think it would be a hard sell.  You'd still want to have something
> like a shared memory queue to exchange messages but on top of
> that you'd have a rather large amount of 9p machinery.
> 

Remember that the shared memory is just one piece of the Xen comms -
they've got all this other cruft for different device classes and bus
provisioning.  That is what we are talking about replacing with 9P -
and while I'm not certain, I think its a pretty good bet that 9P will
end up being more compact that the other cruft and better suited to
transport over different networks when/where necessary.

             -eric

Re: [9fans] 8c question

[Eric Van Hensbergen]

On 7/10/05, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> 
> What we're lacking is anyone with a time to write the proof-of-concept
> implementation. I wish we could get it done, because the inter-domain
> comms in xen just keep getting more and more complex.
> 

Now that he has recover more or less working, Gorka is going to take a
look at this.  Burning a Xen CD for him right now.  A question for you
Ron - would it be bad to prototype on the more stable Xen 2.0?  I'd
hate to waste time if too much of the device channel interface is
chaning for 3.0...

            -eric

Re: [9fans] 8c question

[Ronald G. Minnich]

On Mon, 11 Jul 2005, Eric Van Hensbergen wrote:

> Now that he has recover more or less working, Gorka is going to take a
> look at this.  Burning a Xen CD for him right now.  A question for you
> Ron - would it be bad to prototype on the more stable Xen 2.0?  I'd hate
> to waste time if too much of the device channel interface is chaning for
> 3.0...

newsham can tell us more. But my inclination, given the spin rate of 3.0, 
is to go for 2.0 for proof-of-concept. After all, to get it working on 
3.0, you have to first finish the port of plan 9 to 3.0 ...


it's be nice to have a '#X' or something so:

bind '#X' /dev/xen
and then see /dev/xen/net0, /dev/xen/disk0, and so on, and then

disk/fdisk /dev/xen/disk0/data > /dev/xen/disk0/ctl

bind /dev/xen/net0 /net

and so on.

or maybe the bind would result in stuff like 
/dev/xennet0
/dev/xensd00

etc.

?

Does this sound right or I am way off base here. 

ron

Re: [9fans] 8c question

[Eric Van Hensbergen]

On 7/11/05, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> 
> 
> On Mon, 11 Jul 2005, Eric Van Hensbergen wrote:
> 
> > Now that he has recover more or less working, Gorka is going to take a
> > look at this.  Burning a Xen CD for him right now.  A question for you
> > Ron - would it be bad to prototype on the more stable Xen 2.0?  I'd hate
> > to waste time if too much of the device channel interface is chaning for
> > 3.0...
> 
> newsham can tell us more. But my inclination, given the spin rate of 3.0,
> is to go for 2.0 for proof-of-concept. After all, to get it working on
> 3.0, you have to first finish the port of plan 9 to 3.0 ...
>

Well, we're going to prototype stuff with v9fs on Linux to get stuff
working quickly, then move to Plan 9 native.
 
> 
> it's be nice to have a '#X' or something so:
> 
> bind '#X' /dev/xen
> and then see /dev/xen/net0, /dev/xen/disk0, and so on, and then
> 

Oi - my gut is that this sounds wrong.  What would make more sense is
for #X to look more like devsrv, with the virtual channels
representing.  Then you could mount /dev/xen/dom0 /n/dom0 and then
bind as you like.

        -eric

Re: [9fans] 8c question

[Ronald G. Minnich]

On Mon, 11 Jul 2005, Eric Van Hensbergen wrote:

> Oi - my gut is that this sounds wrong.  What would make more sense is
> for #X to look more like devsrv, with the virtual channels representing.  
> Then you could mount /dev/xen/dom0 /n/dom0 and then bind as you like.

Can those channels correspond to the current channels that talk via fifo 
queue to in-kernel linux devices (the so-called backend devices)?

ron

Re: [9fans] 8c question

[Eric Van Hensbergen]

On 7/11/05, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> 
> 
> On Mon, 11 Jul 2005, Eric Van Hensbergen wrote:
> 
> > Oi - my gut is that this sounds wrong.  What would make more sense is
> > for #X to look more like devsrv, with the virtual channels representing.
> > Then you could mount /dev/xen/dom0 /n/dom0 and then bind as you like.
> 
> Can those channels correspond to the current channels that talk via fifo
> queue to in-kernel linux devices (the so-called backend devices)?
> 

Yeah, well -- sorta.  You probably have a better understanding of the
way Xen does stuff than I do.  I guess in the current context that is
exactly what they would correspond to, but in a 9P-based world, you
would only need a single channel.  You would mount the exported
private namespace containing the devices allocated to your partition
over that channel (instead of individually mounting disk, network,
etc.)

I haven't fully thought through how this would extend across a cluster
yet - but I think a bridging I/O partition would "just work".  Not
sure if I would have "cluster" channels or whether the I/O partition
would mount from other servers and then re-export the resources.

       -eric

Re: [9fans] 8c question

[Ronald G. Minnich]

On Mon, 11 Jul 2005, Eric Van Hensbergen wrote:

> Yeah, well -- sorta.  You probably have a better understanding of the
> way Xen does stuff than I do.  I guess in the current context that is
> exactly what they would correspond to, but in a 9P-based world, you
> would only need a single channel.  You would mount the exported
> private namespace containing the devices allocated to your partition
> over that channel (instead of individually mounting disk, network,
> etc.)

that's not real xen-device-compatible, but let's go with it for now, just
to get proof-of-concept going.

ron

Re: [9fans] 8c question

[Eric Van Hensbergen]

On 7/11/05, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> 
> 
> On Mon, 11 Jul 2005, Eric Van Hensbergen wrote:
> 
> > Yeah, well -- sorta.  You probably have a better understanding of the
> > way Xen does stuff than I do.  I guess in the current context that is
> > exactly what they would correspond to, but in a 9P-based world, you
> > would only need a single channel.  You would mount the exported
> > private namespace containing the devices allocated to your partition
> > over that channel (instead of individually mounting disk, network,
> > etc.)
> 
> that's not real xen-device-compatible, but let's go with it for now, just
> to get proof-of-concept going.
> 

But I thought that was the whole point - to convince them to use 9P
for resource sharing versus the current stuff.  Using 9P for transport
alone just doesn't make sense to me -- let's sell them the whole
enchilada.

       -eric

Re: [9fans] 8c question

[Ronald G. Minnich]

On Mon, 11 Jul 2005, Eric Van Hensbergen wrote:

> But I thought that was the whole point - to convince them to use 9P for
> resource sharing versus the current stuff.  Using 9P for transport alone
> just doesn't make sense to me -- let's sell them the whole enchilada.

you'll lose on the performance front. I'd still like to be able to walk to 
a resource in the kernel and get a channel for it, and then use channel 
reads and writes in the kernel to write the fifo queues. 

Right now, you use a dedicated driver (which is how you name it -- you 
know the driver to use) and drive the fifo queues. 

ah, this is too hard in email. What's the next conference you're going to?

:-)

ron

Re: [9fans] 8c question

[Eric Van Hensbergen]

On 7/11/05, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> 
> 
> On Mon, 11 Jul 2005, Eric Van Hensbergen wrote:
> 
> > But I thought that was the whole point - to convince them to use 9P for
> > resource sharing versus the current stuff.  Using 9P for transport alone
> > just doesn't make sense to me -- let's sell them the whole enchilada.
> 
> you'll lose on the performance front. I'd still like to be able to walk to
> a resource in the kernel and get a channel for it, and then use channel
> reads and writes in the kernel to write the fifo queues.
>

With the new v9fs 2.1 server architecture, I should be able to go zero
copy all the way and match their performance -- at least that's the
plan.

> 
> Right now, you use a dedicated driver (which is how you name it -- you
> know the driver to use) and drive the fifo queues.
> 

I know, I think that sucks.  No reason this can't be unified.  The
performance sensative bits are always reads and writes -- if you can
avoid copies, and I think we can -- particularly over a shared memory
interface, then you should have equivilent performance -- just in a
unified, easy to manage wrapper -- plus we'll have built in fail-over
semantics for certain resources with Gorka's new recover stuff.

         -eric