<div dir="ltr">Please be sure to coordinate your efforts with Hesham so that you don't both propose too much overlap. Also, make sure neither of your proposals/projects is dependent on the other one. More inline below:<br>
<div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 7, 2013 at 11:38 PM, Peng Fan <span dir="ltr"><<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi,<br></div>I have draw a graph to show the basic idea , not software framework. The graph is following the text. The graph can also be accessed from <a href="https://docs.google.com/drawings/d/1vexi53qy0fR9JPujzi02erKy0S8246sVqXtPwWGJ48s/edit?usp=sharing" target="_blank">here</a>.<br>
<br></div>I want to implement both static mapping and dynamic mapping. Both supports dynamic attributes.<br></div>Everything in the framework can be configured depending on what is needed in the development.<br></div>MMU/MPU can be disabled or enabled.If enabled, you can choose coarse-grained mem block or fine-grained mem block.<br>
</div>MPU only supports coarse-grained mem block, such as Region in ARM MPU. <br><br></div></div></div></div></div></div></div></div></div></blockquote><div>I think the static mapping is best done at the lower level, at least for now. Later we can consider some way for application developers to modify the static mapping within the bounds supported by the HW and the linkcmds.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div></div>The 2nd level page table is also supported if fine-grained mem block enabled. This may incur tlb miss.<br>
</div>I have a few questions about 2nd level page.In the mailing list, I found this:<br>
<br>"<br><pre>Yes I overlooked that point.. The "Why" factor.
The number of pages that can be used at one time is a concern for
creating either static or dynamic use of MMU. Using big pages allows
to have a finite number of pages and well-defined "zones" of memory.
Big pages also typically map onto the MMU's TLB directly. Small pages
may permit greater flexibility over the memory mapping, but lets a
developer shoot their foot by using more pages than the TLB can
support and thus induce page faults. We must avoid page faults.
On Tue, Aug 7, 2012 at 3:32 AM, Sebastian Huber
<<a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">sebastian.huber at embedded-brains.de</a>> wrote:
><i> I don't think 2nd level MMU support makes sense for a real-time operating
</i>><i> system.
</i>></pre>"<br></div>why 2nd level MMU support makes no sense?vxworks supports 2nd level.QNX has long offered complete memory protection.<br></div><div>is the time is indefinite because tlb miss?<br></div>If the page faults that caused by tlb miss is the reason, I think this can be handled by low level code.Sure, no swapping.<br>
</div><div>2nd level is a must in fine-grained mem block, I think.<br></div>If I want to protect the private data of the process of only KBs, MBs' protection is too big. If another process's private data is <br></div>
also contained in the MBs, this may incur errors.<br></div>Anyhow, all is configurable, fine or coarse-grained, dynamic or static mapping, mmu enable or disable.<br></div>any comments? Thanks.<br></div></blockquote><div>
In a real-time system, the overhead to handle a TLB miss is problematic. We cannot allow a TLB miss to happen in application code. So, the TLB needs to be pre-filled with all of the valid mappings. Even with dynamic changes, we should limit the overhead of flushing/filling the MMU/MPU structures and align the costs with well-defined boundaries preferably in a non-realtime task, such as during initialization or dynamic linking. Architectures that support selective modification of the MMU/MPU can support dynamic changes in a context switch, but if a dynamic change on some MMU requires flushing the TLB or (worse) the cache, then I don't think anyone will find the dynamic changes tenable for a realtime application.<br>
<br></div><div>-Gedare<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>
<div><div><div><div><div><div><div><div><div><div><div><div class="gmail_extra"><img alt="内嵌图片 4" src="cid:ii_13de7a6305d6db6a" height="560" width="815"><br></div><div class="gmail_extra">Regards,<br>Peng.<br></div><div>
<div class="h5"><div class="gmail_extra">
<br><div class="gmail_quote">2013/3/30 Peng Fan <span dir="ltr"><<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div><div><div><div>Hi,<br></div>The doc is just for learning and I'll put the reference sources there.I am not intended to volatile any international copyright laws and hope it may not. <br></div>I am still thinking about how to design the framework and I'll put it in another doc.<br>
<br></div>Regards,<br></div>Peng.<div><div><br><div><div><div><div><div><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">2013/3/30 Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I have some concern about where your information has come from on these design notes. Please be sure not to violate any international copyright laws in your work. It would be best if you can point to official vxworks documentation or reference sources.<span><font color="#888888"><br>
<br></font></span></div><span><font color="#888888">-Gedare<br></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 29, 2013 at 1:50 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>This is pretty good. Please note that we do not want to copy the design (unless it is good!), and definitely none of the code! While you're looking at this, maybe including what some other open RTOSs support would be a good idea.<br>
</div><br></div>What we need to get to is a set of requirements for MMU/MPU management. Then we can work on an RTEMS design to satisfy those requirements.<span><font color="#888888"><br><br></font></span></div>
<span><font color="#888888">-Gedare</font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Mar 29, 2013 at 9:02 AM, Peng Fan <span dir="ltr"><<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div><div><div>I have write a simple document of mmu of vxworks.I hope it maybe useful for the design of rtems mmu.<br><br><a href="https://docs.google.com/document/d/1-f9bb_3H14SZr9d8GvA5KJGOcP8l2QjIwxTYkMMHTGU/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1-f9bb_3H14SZr9d8GvA5KJGOcP8l2QjIwxTYkMMHTGU/edit?usp=sharing</a><br>
<br></div>Anyone can comments.There might be some errors and thanks for your pointing it out.<br><br></div>Regards,<br></div>Peng<div><div><br><div><div><div><div><div><div><div><br><div class="gmail_quote">---------- Forwarded message ----------<br>
From: <b class="gmail_sendername">Gedare Bloom</b> <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span><br>Date: 2013/3/27<br>Subject: Re: A Well Defined Framework Design and Implementation for RTEMS MMU(Peng Fan -Gsoc2013 proposal) (<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>)<br>
To: Peng Fan <<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>><br>Cc: Joel Sherrill <<a href="mailto:joel.sherrill@gmail.com" target="_blank">joel.sherrill@gmail.com</a>><br><br>
<br><div dir="ltr">Please consider sending your thoughts to rtems-devel mailing list.<br>
<div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Wed, Mar 27, 2013 at 12:55 AM, Peng Fan <span dir="ltr"><<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,<br><br></div><div>The following is a few of my thoughts.<br></div><div><br>
</div>
<div>1.The mmu management part of section 3.8</div><div>1.1</div><div> The following is based on dynamic MMU management.</div>
<div>1.1.1</div><div> a section is big block memory that is mapped to a task's address space.The map is done when the task allocates the section. a segment is allocated from a section. The protection level is on the section level. right? I am confused with Partion of 3.8.3 that why protection is on the partition level.I think Partition should be a fine-grained memory within the coarse-grained section.</div>
</div></blockquote></div><div>Section may be some architecture-dependent feature. The focus of the document I sent was the MMU support for M68851 and M68030. We want to consider many more CPUs and MMU/MPU combinations.<br>
<br>
</div>
<div>A partition is a different construct than a region. Try not to conflate the two ideas. <br><br>A region lets a task allocate segments. The point of 3.8.2 is that the region does not need to be mapped into each task's address space, only the allocating task needs to have access to the entire region. Any other tasks that share the region can be given access to only the requested segments.<br>
<br></div><div>A partition lets a task allocate buffers. The entire partition is mapped into a task's address space, and every task sharing the partition will have access to all of the buffers allocated from it.<br></div>
<div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div>1.1.2</div><div> In the current implementation of rtems, different tasks can get region or partition buffer from a region or partition?</div><div>I am not sure about this. a section is owned to a task. Thus, can different tasks get buffer from regions allocated from section?Maybe it's not thread safe. Maybe an attribute shoule be added to section to indicate whether it's a section can be shared by different tasks or it's owned only by</div>
<div>one task.</div><div><br></div></div></blockquote></div><div>There is no idea of ownership or protection in RTEMS right now. RTEMS implements a single address space. You can read the current documentation at <a href="http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/index.html" target="_blank">http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/index.html</a><br>
<br></div><div>How best to deal with ownership of memory ranges remains an open question.<br></div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div></div><div>1.2 </div><div>About MPU related.</div><div>You said Some developers maybe want a better way to create the static mapping but do not care about dynamic,especially on systems without a true mmu but just using a mpu. I think the static mapping related data structure should be defined in the Mid level,the mapping table just like mem_map should be static defined in Low level.The static mapping related interfaces should not be exposed to application but application wants to change the attributes of the static mapping. The high level api in my opinion is exposed only to application layer just like the rtems's C manual listed.</div>
<div><br></div></div></blockquote></div><div>Sure, but we still need to provide a way to modify or configure the static mapping without a user needing to modify the BSP code. Although, I'm not entirely sure how feasible it is to provide an alternate static mapping without changing some BSP files like the linker script (linkcmds).<br>
</div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>2. About "page"</div><div>
The page in my proposal should be the same with the section in 1.1.1. I just have no good words to express my meaning. I searched the mailing list and I found TLB related problems. Maybe fine-grained mem block should be allocated through region or partition but not two-level page tables. Because TLB fault should be handled carefully especially for MIPS in low level code, if two level page tables are implemented.</div>
<div><br></div></div></blockquote></div><div>Discuss this with Hesham and ask for access to his prior documents. We went back and forth about this issue. The main problem is that different architectures define different terminology, e.g. section, page, segment, and so forth.<br>
<br></div><div>I don't think we should right now implement any interfaces that rely on page tables. Instead we should translate the capabilities of different MMU/MPU hardware to support static and dynamic memory mappings/protection.<br>
</div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>3. About VxVMI</div><div>I am still reading the docs and code to give myself a basic framework of vxworks'MMU design.I'll give my feedback about this soon.</div>
</div></blockquote></div><div>OK. I'm not really that familiar with it myself, so a report would be helpful to me.<br></div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div><br></div><div>4. About the platform</div>
<div>what I have now are only a pandaboard(omap4460) and a s3c6410 development board,but there are no rtems bsp for this.which platform do you suggest me to use? If needed, I may port it to qemu to facilitate debugging.</div>
<div><br></div></div></blockquote></div><div>Use a simulator. For powerpc we have MMU support working on psim, which is based in GDB. I don't know how many of the other GDB simulators implement MMU features in their simulators. Hesham I think had gumstix with skyeye sort of working, but I think he said the Skyeye does not really implement the MMU. I think Qemu would be useful, if you can find the right cpu/BSP in RTEMS to use on Qemu. You'd have to ask on rtems-users about what BSPs people might be using on Qemu.<br>
<br></div><div>The advantage of a simulator is that it makes it easier for others to try out your work and give feedback.<br></div><div><br></div><div>I would also encourage you to try using the Panda board with the BSP support provided by a student from last year's GSOC, Xi Yang <a href="mailto:hiyangxi@gmail.com" target="_blank">hiyangxi@gmail.com</a> whose code I don't think has been merged yet, but provides OMAP support so that RTEMS can run on the small MCUs and interoperate with Linux on the main processor. It would be great if you can try to get that platform to work, as it would give another verification for us that the BSP support works. Right now, only Xi has tested it. You'll have to contact him for more details.<br>
</div><div><div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Regards,<br></div><div>Peng<br></div><div><br></div></div><div>
<div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/3/26 Peng Fan <span dir="ltr"><<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks for your reply. I'll read the documents listed in the mail and search through the mailing lists.<br>
</div>The picture in the proposal maybe is not so clear.Anyhow, I will read the docs first. Thanks again.<span></span></div><div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">2013/3/26 Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@gmail.com" target="_blank">joel.sherrill@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Mon, Mar 25, 2013 at 11:47 AM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">A clean room implementation of VxVMI would be a good place to start, albeit with RTEMS-branded interface names; but a clear relationship between the two can make someone's porting job (or adding to OSAL) easier. You can also look for info about RTP "Real-Time Processes".. I'm not convinced they are "Real-time" but that is another VxWorks artifact that might inform design decisions.<br>
</div><div><div><div class="gmail_extra"><br><br></div></div></div></blockquote><div><br></div></div><div>For better or worse, we get compared to VxWorks. :(</div><div><br></div><div>VxVMI at least gives a concrete example of what capabilities are useful.</div>
<div><div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 25, 2013 at 12:28 PM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@gmail.com" target="_blank">joel.sherrill@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br><div class="gmail_quote"><div>On Mon, Mar 25, 2013 at 10:25 AM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div><div><div><div><div>Hi,<br><br>You can search through rtems-devel mailing list for some various
conversations we have had related to memory protection / MMU support.
(Somehow I think you can make Google search only in the rtems-devel
mailing list archive, but I don't recall offhand the Google-fu required
to make that work.)<br><br></div></div></div></div></div></div></blockquote><div><br></div></div><div>MMU site:<a href="http://www.rtems.org/pipermail/rtems-devel/" target="_blank">www.rtems.org/pipermail/rtems-devel/</a></div>
<div><br></div>
<div>With "site:" you can restrict the search to a domain or a starting path.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div><div><div><div><div></div>It may also make sense to divide the low-level/mid-level work to be done between you and Hesham. For example, you might identify if there are any MIPS or X86 targets that could benefit from the low-level MMU implementation. I believe Hesham will focus on the ARM and PowerPC.<br>
<br></div>Please note that not all MMU will support the notion of paging. We need to have a good idea of the requirements for high-level MMU support. Some developers maybe want a better way to create the static mapping but do not care about dynamic, especially on systems without a true MMU but just using an MPU. Others might want the dynamic support, but only some of the time.<br>
</div><br></div>Another place to look is at the original documentation for RTEMS specifications. Although ORKID did not provide for MMU management, RTEID did so, and I am attaching the relevant documentation set here. See section 3.8 MMU Management for some ideas. This documentation gives some ideas about how to use an MMU with the Regions and Partitions services, and provides some high-level interface definitions that might be useful for how we think about dynamic MMU management.<span><font color="#888888"><br>
<br></font></span></div></div></blockquote></div><div>Other sources of information include... other RTOSes. A quick Google turned up this</div><div>which gives some insight:</div><div><br></div><div><a href="http://www.uio.no/studier/emner/matnat/fys/FYS4220/h11/undervisningsmateriale/laboppgaver-rt/vxworks_architecture_supplement_6.2.pdf" target="_blank">http://www.uio.no/studier/emner/matnat/fys/FYS4220/h11/undervisningsmateriale/laboppgaver-rt/vxworks_architecture_supplement_6.2.pdf</a></div>
<div><br></div><div>VxVMI is Wind River's product in this domain. Any references to this product</div><div>will help formulate use cases. I found this by Paul Chen who I have actually worked</div><div>with on a standards effort:</div>
<div><br></div><div><a href="http://ftp.ruigongye.com/200804/wp_vxworks_vxvmi.pdf" target="_blank">http://ftp.ruigongye.com/200804/wp_vxworks_vxvmi.pdf</a></div><div><br></div><div>Here are a couple of man pages for their vmlib()</div>
<div>
<br></div><div><a href="http://www.vxdev.com/docs/vx55man/vxworks/ref/vmLib.html" target="_blank">http://www.vxdev.com/docs/vx55man/vxworks/ref/vmLib.html</a></div><div><a href="http://www.vxdev.com/docs/vx55man/vxworks/ref/vmShow.html" target="_blank">http://www.vxdev.com/docs/vx55man/vxworks/ref/vmShow.html</a></div>
<div><br></div><div>And the manual.</div><div><br></div><div><a href="http://www.vxdev.com/docs/vx55man/vxworks/guide/c-vm.html" target="_blank">http://www.vxdev.com/docs/vx55man/vxworks/guide/c-vm.html</a></div><div><br>
</div><div>VxVMI is AFAIK the base set of capabilities we need to have to</div>
<div>be competitive.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span><font color="#888888"></font></span></div>
<span><font color="#888888">-Gedare<br><div><div><div><br><br></div></div></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 24, 2013 at 11:09 PM, Peng Fan <span dir="ltr"><<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>Hi joel,Gedare.<br></div> I have just finished a draft of my proposal.Hope you can give me some advice.<br>
</div> I have contacted Heshman.He said that he intends to enhance low-level/Mid-level APIs.<br>
</div> Thus I think I may work on high-level API design.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">在 2013年3月25日上午11:04，Peng Fan (Google 云端硬盘) <span dir="ltr"><<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>></span>写道：<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div style="max-width:650px;font-family:Arial,sans-serif;border:1px solid rgb(240,240,240)"><div style="padding:14px 10px 4px;line-height:21px;margin-bottom:13px"><span style="font-size:20px;color:rgb(51,51,51)">我与您共享了一个项。</span></div>
<div style="font-size:13px;padding:0px 7px 7px 10px">
<table cellpadding="0" cellspacing="0"><tbody><tr><td style="vertical-align:top;padding-bottom:7px;font-size:16px;text-align:center"><img alt="文档" style="vertical-align:middle"></td>
<td style="vertical-align:top;padding-bottom:7px;font-size:16px;padding-left:5px">
<span><a href="https://docs.google.com/document/d/1lZINtGmSw5HFgdmvAQM0b2B1aAvervFoIZNAArGIAig/edit?usp=sharing" style="vertical-align:middle;text-decoration:none;color:rgb(17,84,204)" target="_blank">A Well Defined Framework Design and Implementation for RTEMS MMU(Peng Fan -Gsoc2013 proposal)</a>
</span></td></tr></tbody></table>
</div>
<div style="background-color:rgb(245,245,245);padding:2px 12px"><table style="width:100%" cellpadding="0" cellspacing="0"><tbody><tr><td style="padding:0px;color:rgb(128,128,128);font-size:11px" valign="middle">Google 云端硬盘：在同一位置创建、共享和保存您的所有资料。</td>
<td style="text-align:right" valign="middle"><a href="https://drive.google.com" target="_blank"><img style="border:0px none;vertical-align:middle;padding-top:12px;padding-bottom:4px;margin-left:34px" alt="Google 云端硬盘的徽标"></a></td>
</tr></tbody></table></div></div></div></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div><br>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div></div></div></div>
</div><br></div></div></div></div></div></div></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div><br></div></div></div>