Mailing List Archive

xen vbd: better.
OK, this is all boiling down to 8c/gcc differences of opinion.
Interesting, as things were designed in the Xen communications with the
reasonable expectation that on the same architecture you ought to be able
to pass around binary structs in event channels without standard RPC
marshall/de-marshall guck. That's how I read it anyway.

It's portable on same machine, same compiler, even to different OSes, but
not to same machine, different compiler. Interesting. So I am having to
put marshall/demarshall code into the Plan 9 code that sends messages to
Xen.

And yes, I'm well aware that kencc isn't C9x, but ... it's a nice C
anyway.

Now, I am getting back a nonsensical result for the disk size.

The partition in question is /dev/hda1, which is this:

Disk /dev/hda: 60.0 GB, 60011642880 bytes
240 heads, 63 sectors/track, 7752 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 1324 10009408+ 7 HPFS/NTFS
/dev/hda2 1325 7154 44074800 83 Linux
/dev/hda3 7155 7287 1005480 82 Linux swap

(yes, I plan to wipe out Windows/XP in favor of Plan 9 on Xen).

The info packet for that partition comes back as this:
0x0: 02 4f 6e 00 00 00 00 00 01 03 e0 00

translated, it is 0x6e4f02 of capacity, 0x301 device (hda1! yay!), flags
e0 (DISK, VIRTUAL, READONLY) (all of which I understand save VIRTUAL -- I
guess that means a partition, not the whole disk).

0x6e4f02 is in decimal 7229186. That number makes no sense. It's not the
number of blocks, or the number of bytes per unit, or ...

Can somebody clear me up on this simple algebra problem?

thanks

ron


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: xen vbd: better. [ In reply to ]
>
> OK, this is all boiling down to 8c/gcc differences of opinion.
> Interesting, as things were designed in the Xen communications with the
> reasonable expectation that on the same architecture you ought to be able
> to pass around binary structs in event channels without standard RPC
> marshall/de-marshall guck. That's how I read it anyway.
>
> It's portable on same machine, same compiler, even to different OSes, but
> not to same machine, different compiler. Interesting. So I am having to
> put marshall/demarshall code into the Plan 9 code that sends messages to
> Xen.

It certainly should be portable to any machine, any compiler, modulo:
1. Endianness issues
2. A sane compiler that supports packed structs.

How can you get any low-level systems work done without supporting
data interoperability via packed structs? How can you define sane
network header structs for example? You can't know that your compiler
won't pack your IP header layout incorrectly!

The endianness issues we can deal with later if necessary. Generally I
expect that we won't be messaging cross-architecture so it'll be a
non-issue.

> The info packet for that partition comes back as this:
> 0x0: 02 4f 6e 00 00 00 00 00 01 03 e0 00
>
> translated, it is 0x6e4f02 of capacity, 0x301 device (hda1! yay!), flags
> e0 (DISK, VIRTUAL, READONLY) (all of which I understand save VIRTUAL -- I
> guess that means a partition, not the whole disk).
>
> 0x6e4f02 is in decimal 7229186. That number makes no sense. It's not the
> number of blocks, or the number of bytes per unit, or ...
>
> Can somebody clear me up on this simple algebra problem?

It is the capacity in 512-byte sectors.

-- Keir


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: xen vbd: better. [ In reply to ]
On Fri, 22 Oct 2004, Keir Fraser wrote:

> > translated, it is 0x6e4f02 of capacity, 0x301 device (hda1! yay!), flags
> > e0 (DISK, VIRTUAL, READONLY) (all of which I understand save VIRTUAL -- I
> > guess that means a partition, not the whole disk).
> >
> > 0x6e4f02 is in decimal 7229186. That number makes no sense. It's not the
> > number of blocks, or the number of bytes per unit, or ...
> >
> > Can somebody clear me up on this simple algebra problem?
>
> It is the capacity in 512-byte sectors.

yes, but it's wrong, which is where I'm stuck.
7229186 512 * p
3701343232

it's a 10G partition, not an 3.7G partition. Any other ideas as to what
could be happening here.

ron


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: xen vbd: better. [ In reply to ]
On Fri, 22 Oct 2004, Keir Fraser wrote:

> How can you get any low-level systems work done without supporting
> data interoperability via packed structs? How can you define sane
> network header structs for example? You can't know that your compiler
> won't pack your IP header layout incorrectly!

it's interesting to see the very different thoughts in the Plan 9
community (Ken included) about this issue. Basic feeling over there is
that putting packed structs into the compiler is a terrible idea, not
needed, it's deprecated, and should never be used. That's my polite
translation :-)

Plan 9 works just fine without packed structs, as do the many operating
systems written by people using compilers that didn't do packed structs
either, or even compilers that always packed structs (V6 C). All these
systems twiddled bits just fine.

Anyways, I'll stick with unpacking and packing them myself. Here's an
interesting cultural issue (at least to me) brought up by a simple
compiler switch!

ron


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: xen vbd: better. [ In reply to ]
> it's interesting to see the very different thoughts in the Plan 9
> community (Ken included) about this issue. Basic feeling over there is
> that putting packed structs into the compiler is a terrible idea, not
> needed, it's deprecated, and should never be used. That's my polite
> translation :-)
>
> Plan 9 works just fine without packed structs, as do the many operating
> systems written by people using compilers that didn't do packed structs
> either, or even compilers that always packed structs (V6 C). All these
> systems twiddled bits just fine.

I'm interested to know how. How do you define a network header layout,
for example, and how do you access subfields? e.g., is there an
explicit IDL with integration into the compiler?

-- Keir


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: xen vbd: better. [ In reply to ]
On Fri, 22 Oct 2004, Keir Fraser wrote:

> I'm interested to know how. How do you define a network header layout,
> for example, and how do you access subfields? e.g., is there an
> explicit IDL with integration into the compiler?

it's the old fashioned way. You pack and unpack from an array of unsigned
chars. It sounds painful, but there's so little of it needed that it
really doesn't matter much. In 15 years of working on this kernel nobody
has ever felt the need, and although they did end up adding __packed__
into the compiler in some form, they hated it for practical and esthetic
reasons; hence its use is "deprecated". The kernel functions that do the
pack/unpack are tiny and have not changed in forever.

Having done this both way myself many times, I'd have to come down right
on the middle of the fence. Yah, having the compiler pack is nice. No,
it's actually not foolproof in all cases on all compilers for all time --
so it's out there waiting to bite you. And, the 'unpack it yourself' is in
actual practice more portable -- at least that's how it's been for me
(well, and many others). Weird but true.

There's a lot of interesting philosophical arguments to be made on either
side, I'm just reporting them. Having solved my problems (almost) with
the vbd, I'm going to move along now :-)

[VBD reported size still makes no sense at all]


ron


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: xen vbd: better. [ In reply to ]
On Fri, Oct 22, 2004 at 08:08:18PM +0100, Keir Fraser wrote:

> > Plan 9 works just fine without packed structs, as do the many operating
> > systems written by people using compilers that didn't do packed structs
> > either, or even compilers that always packed structs (V6 C). All these
> > systems twiddled bits just fine.
>
> I'm interested to know how. How do you define a network header layout,
> for example, and how do you access subfields? e.g., is there an
> explicit IDL with integration into the compiler?

Typically fixed-format data structures are done by simply accessing the data
as a char[] array instead of a struct. This may not be as pretty, but it
compiles down into the same machine code and it's 100% portable. (And you
can do it pretty decently with some preprocessor macros.)

Have fun,

Avery


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel