Xen devel - Jun 2006 - FW: Is it a correct place for VBD information?

A little while ago, I send modified VBD information patch.

However, I does not sit well with location.
I does not find statistical information under ''device''
directory, and see them under ''class'' directory for vif.
(/sys/class/net) But, there are not appropriate location. (/sys/class/vbd or
/sys/class/block)

Is it a correct place for such type of information?
Is it necessary to make symbolic links to other places?
Where is appropriate place?
Please comment.


I think that it is good to handle such information at one partial tree for
management.
My idea is to take a kind of following structure for store such information.

   sys -- class -- xen --+-- domain0 --- balloon ( symlink to
/sys/class/mem/balloon ?)
                                 |
                                +-- domain1 --+-- vbd --+-- vbd-x-xxxx(symlink?)
                                                     |            |
                                                     |            +-- total
information file.
                                                     |
                                                    +-- vif --
vif-x-xxxx(symlink)
 
Please comment.


Thanks,
Satoshi UCHIDA.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Satoshi Uchida wrote:
>  A little while ago, I send modified VBD information patch.
> 
> However, I does not sit well with location.
> I does not find statistical information under ''device''
directory, and see them under ''class'' directory for vif.
(/sys/class/net) But, there are not appropriate location. (/sys/class/vbd or
/sys/class/block)
> 
> Is it a correct place for such type of information?
> Is it necessary to make symbolic links to other places?
> Where is appropriate place?
> Please comment.
> 
> 
> I think that it is good to handle such information at one partial tree for
management.
> My idea is to take a kind of following structure for store such
information.
> 
>    sys -- class -- xen --+-- domain0 --- balloon ( symlink to
/sys/class/mem/balloon ?)
>                                  |
>                                 +-- domain1 --+-- vbd --+--
vbd-x-xxxx(symlink?)
>                                                      |            |
>                                                      |            +-- total
information file.
>                                                      |
>                                                     +-- vif --
vif-x-xxxx(symlink)
>  

What about /sys/hypervisor/xen/domain/1/vbd

/sys/hypervisor is going into upstream linux, and that leaves 
/sys/hypervisor/xen/ as our namespace for info.

Mike

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Thanks for comment, Mike.
>> 
>> I think that it is good to handle such information at one partial tree
for management.
>> My idea is to take a kind of following structure for store such
information.
>> 
>>    sys -- class -- xen --+-- domain0 --- balloon ( symlink to
/sys/class/mem/balloon ?)
>>                                  |
>>                                 +-- domain1 --+-- vbd --+--
vbd-x-xxxx(symlink?)
>>                                                      |            |
>>                                                      |            +--
total information file.
>>                                                      |
>>                                                     +-- vif -- 
vif-x-xxxx(symlink)
>>  
>What about /sys/hypervisor/xen/domain/1/vbd
In Xen, devices is not handled with hypervisor but is handled with Domain0 (or
the privileged domain).
So, Shouldn''t these information locate under /sys/hypervisor ?

What does /sys/hypervisor mean?
For example, I feel /sys/firmware means structure in namespace.
If /sys/hypervisor is similar to these information,
these information shouldn''t locate under /sys/hypervisor.
If /sys/hypervisor create as new tree which is to handle total information for
virtual system,
It may be good that these information locate under /sys/hypervisor.

/sys/class means description of a type of device (see
Documentation/device-model/class.txt),
and each device class defines a set of semantics and programming interface.
Xen is not device, so it may be bad that  these information locate under
/sys/class.

/sys/devices means filesystem representation of the device tree.
So, I feel that these statistical information shouldn''t locate under
/sys/devices

I can not find reasonable answer.
Please help.

How about making a new tree -- /sys/xen ?

>/sys/hypervisor is going into upstream linux, and that leaves
/sys/hypervisor/xen/ as our namespace for info.
Good.
But I hesitate by above reason for /sys/hypervisor/xen.


Satoshi UCHIDA


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 26 Jun 2006, at 03:03, Satoshi Uchida wrote:
> /sys/class means description of a type of device (see 
> Documentation/device-model/class.txt),
> and each device class defines a set of semantics and programming 
> interface.
> Xen is not device, so it may be bad that  these information locate 
> under /sys/class.
>
> /sys/devices means filesystem representation of the device tree.
> So, I feel that these statistical information shouldn''t locate
under
> /sys/devices
There''s all kinds of device-specific metadata under device directories 
in /sys/devices. So placing statistics under there seems fine to me as 
it keeps device-specific data together in one place -- the vbd 
directories can then get symlinked from /sys/class or 
/sys/hypervisor/xen in future if that is deemed to make sense, and all 
vbd-specific info is at once available at those new locations.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> On 26 Jun 2006, at 03:03, Satoshi Uchida wrote:
> 
> > /sys/class means description of a type of device (see 
> > Documentation/device-model/class.txt),
> > and each device class defines a set of semantics and programming 
> > interface.
> > Xen is not device, so it may be bad that  these information locate 
> > under /sys/class.
> >
> > /sys/devices means filesystem representation of the device tree.
> > So, I feel that these statistical information shouldn''t
> locate under
> > /sys/devices
> 
> There''s all kinds of device-specific metadata under device
directories
> in /sys/devices. So placing statistics under there seems fine to me as 
> it keeps device-specific data together in one place -- the vbd 
> directories can then get symlinked from /sys/class or 
> /sys/hypervisor/xen in future if that is deemed to make sense, and all 
> vbd-specific info is at once available at those new locations.
> 
>   -- Keir
> 
OK.

On the  presumption that statistical information is placed in /sys/device, 
I think that the first stage in output of VBD information is the end at ver. 2
patch.
How is it?


Thanks,
Satoshi UCHIDA.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 27 Jun 2006, at 06:45, Satoshi Uchida wrote:
> OK.
>
> On the  presumption that statistical information is placed in 
> /sys/device,
> I think that the first stage in output of VBD information is the end 
> at ver. 2 patch.
> How is it?
Another version is required:
Formatting is a bit off (e.g., xenvbd_sysfs_delif) -- please make sure 
you observe Linux coding style everywhere. Also the code would all be 
better off in xenbus.c -- it''s where it gets invoked from and then you 
won''t need to modify the shared header file at all. Get rid of 
fmt_ulong[] -- the compiler should optimise identical string literals.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, Kier.
> 
> On 27 Jun 2006, at 12:28, Satoshi Uchida wrote:
> 
> >
> > Sorry.
> > You will be sure What I mean hear  by following patch.
> > I sent this patch formally after applying the sysfs patch.
> > This patch is to clear code, namely no give additional 
> function, so I 
> > do not sent now.
> 
> Do you really think that''s better than just writing the 
> string literals directly in the macro uses?
> 
> e.g.,
> VBD_SHOW(physical_device, "%x:%x", be->major, be->minor); 
> VBD_SHOW(mode, "%s", be->mode);
> 
> Also, the "\n" can be removed from the caller strings and 
> placed inside the VBD_SHOW macro:
>   .... format "\n" .....
> 
> The compiler will concatenate the string literals.
> 
I think that it is OK using macros or literals.

In Linux net/core/net-sysfs.c., the ''fmt'' representation is
used by statistical data.
In the other, it is used literals or define show function directly.
Therefore, representation will be not unified in detail.
(Perhaps, macro is not better in net/core/net-sysfs.c)

I think that it is useful for recognizing data type and interesting,
and so used fmt representation.

In Linux, "\n" is written in format even if using literals.
However, I think that above representation is interesting and 
want to use idea if using literals.

Please comment, using fmt macro or literals.



Thanks
Satoshi UCHIDA


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 28 Jun 2006, at 02:15, Satoshi Uchida wrote:
> In Linux net/core/net-sysfs.c., the ''fmt'' representation
is used by
> statistical data.
> In the other, it is used literals or define show function directly.
> Therefore, representation will be not unified in detail.
> (Perhaps, macro is not better in net/core/net-sysfs.c)
Using a macro for the function makes sense here, rather than 
duplicating a multi-line function block.
> I think that it is useful for recognizing data type and interesting,
> and so used fmt representation.
>
> In Linux, "\n" is written in format even if using literals.
> However, I think that above representation is interesting and
> want to use idea if using literals.
>
> Please comment, using fmt macro or literals.
Literals are clearer here. Then the macro invocations read like a 
printf() style of call.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel