Hi, 
>
> On 24/8/07 09:27, "Satoshi Uchida" <s-uchida@xxxxxxxxxxxxx> wrote:
>
> > 
> > Therefore, I think that it is better to develop OS-agnostic 
> I/O control.
>
> Another nice thing would be that if we do not use CFQ then we 
> do not need a kernel thread per VBD. We could support one 
> kernel thread per blkback and one kernel thread per VBD.
>
> I don't know if both these models can be neatly supported by 
> a single consistent set of iomgr hooks.
First, I fell that integrating into one kernel thread is a nice ways.
I/O requests can be controlled only by implementing any queuing techniques, and 
it is not need to control threads
However, usage of thread per VBD has advantage of simplifying to control event 
channels (ring buffer) and to manage information of VBDs (rd-reqs wr-reqs, 
...), etc.
So, I think that it is not needed to unite their threads.
> > Does this mean that interfaces should not be implemented by 
> insmod or 
> > rewriting sysfs entries, but should be implemented by 
> xenstore and xm 
> > commands?
>
> Hmmm... Well actually all the blkdev stats are exported thru 
> sysfs right now, so already there are things that do not work 
> well when blkback is in a driver domain (e.g., xentop). 
> Perhaps we should export everything thru sysfs, but then 
> provide a way to proxy that info through xenstore too, as an 
> optional extra (either a user-space daemon, or we could make 
> it a kernel driver option).
>
OK.
It is nice to implement interface via xenstore.
The xenstore is implemented on any OS (Linux or Solaris) and it will be 
implemented on other OSs in future.
Maybe, there are sysfs in only Linux and there are not sysfs in other OS.
-- Perhaps there are similar systems such as devfs. --
Therefore, Using sysfs interface becomes OS-specific, but using xenstore is 
OS-agnostic.
Thanks,
--------------------------------------
Satoshi UCHIDA
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel