<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>hotsolaris的专栏</title><link>http://blog.csdn.net/hotsolaris/</link><description>声明：本博客中的大部分内容收集自互联网，供学习交流使用。</description><dc:language>zh-CN</dc:language><lastUpdateTime>Thu, 09 Jul 2009 13:29:00 GMT</lastUpdateTime><ttl>60</ttl><item><dc:creator>Allen Lu</dc:creator><title>PCI device identification and driver binding in Solaris</title><link>http://blog.csdn.net/hotsolaris/archive/2009/07/09/4334008.aspx</link><pubDate>Thu, 09 Jul 2009 13:28:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/07/09/4334008.aspx</guid><description>&lt;br /&gt;This is a blog article written by Dan Mick, http://blogs.sun.com/dmick/entry/title_pci_device_identification_and&lt;br /&gt;&lt;br /&gt;A PCI device has a bunch of device identification numbers associated
with it, which generic code can retrieve.  I've listed them here in
most-specific to least-specific order, by their Solaris property name
(shown in the prtconf -pv
 output, which is why we always always always
ask for that when diagnosing driver-binding problems): revision (not useful on its ow&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4334008.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>Locking and Synchronization in Solaris kernel</title><link>http://blog.csdn.net/hotsolaris/archive/2009/07/02/4315936.aspx</link><pubDate>Thu, 02 Jul 2009 13:31:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/07/02/4315936.aspx</guid><description>&lt;br /&gt;1. Parallel System Architecture&lt;br /&gt;
        SMP - Symmetric multiprocessor with a shared memory model; single kernel image&lt;br /&gt;
        MPP - Message-based model; multiple kernel images&lt;br /&gt;
        NUMA/ccNUMA - Shared memory model; single kernel images&lt;br /&gt;&lt;br /&gt;
2. Hardware Considerations for Locks and Syncronization&lt;br /&gt;
        Consideration:&lt;br /&gt;
        (1) need For an automatic test-and-set instruction for locking primitives&lt;br /&gt;
        (2) Data global visibility is&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4315936.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>How to dump, extract and iasl acpi tables on x86 platform</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/26/4301330.aspx</link><pubDate>Fri, 26 Jun 2009 16:47:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/26/4301330.aspx</guid><description>&lt;br /&gt;You need the following packages to install on your Nevada:&lt;br /&gt;&lt;br /&gt;acpidump - acpi power management utilities&lt;br /&gt;iasl - Intel ASL compiler/decompiler&lt;br /&gt;&lt;br /&gt;If you are using OpenSolaris200906, IPS can help you to install these tools.&lt;br /&gt;&lt;br /&gt;The binary files are installed under &lt;br /&gt;&lt;br /&gt;[allen@blu-nhm:~]which acpidump&lt;br /&gt;
/opt/csw/bin/acpidump&lt;br /&gt;&lt;br /&gt;# acpidump &gt; acpi.bin&lt;br /&gt;&lt;br /&gt;# acpixtract -a acpi.bin &lt;br /&gt;
Acpi table [DSDT] - 26643 bytes written to DSDT&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4301330.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>disable graphic login</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/24/4294429.aspx</link><pubDate>Wed, 24 Jun 2009 14:40:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/24/4294429.aspx</guid><description>&lt;br /&gt;Run the following two commands and reboot.&lt;br /&gt;&lt;br /&gt;svcadm disable cde-login&lt;br /&gt;
  svcadm disable gdm&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4294429.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>panic or panick?</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/19/4283733.aspx</link><pubDate>Fri, 19 Jun 2009 18:37:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/19/4283733.aspx</guid><description>&lt;br /&gt;If English is not your native language, you may misused panic and panick in code comment. Keep this in mind, panic is a noun and panick is it's correspoding verb.&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4283733.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>how to convert a virutal address to physical address in Solaris driver</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/19/4283726.aspx</link><pubDate>Fri, 19 Jun 2009 18:33:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/19/4283726.aspx</guid><description>&lt;br /&gt;Below discussion posted in osol-code mailing list tells how to use ddi interface to convert virtual address to physical address in Solaris driver.&lt;br /&gt;&lt;br /&gt;====&lt;br /&gt;&lt;br /&gt;If you are writing a device driver, or porting one, then you're going about this entirely the wrong way. These APIs should only be used by low level platform code, not from within device drivers. In fact, hat_getkpfnum generates warnings if you use it!&lt;br /&gt;&lt;br /&gt;Assuming that this is an ordinary device driver, and n&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4283726.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>videos and foils for Community One event</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/18/4280191.aspx</link><pubDate>Thu, 18 Jun 2009 16:00:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/18/4280191.aspx</guid><description>&lt;br /&gt;http://wikis.sun.com/display/OpenSolaris/OpenSolaris+at+C1+West+-+Schedule&lt;br /&gt;&lt;br /&gt;Have fun.&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4280191.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>A brief introduction to XenStore: Format and Interface</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/18/4278620.aspx</link><pubDate>Thu, 18 Jun 2009 10:25:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/18/4278620.aspx</guid><description>About&lt;br /&gt;&lt;br /&gt;This document describes the format of the entries in XenStore, how and what they're used for, and how third-party apps should use XenStore as a management interface. &lt;br /&gt; Overview&lt;br /&gt;&lt;br /&gt;XenStore
is a hierarchical namespace (similar to sysfs or Open Firmware) which
is shared between domains. The interdomain communication primitives
exposed by Xen are very low-level (virtual IRQ and shared memory). XenStore
is implemented on top of these primitives and provides some h&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4278620.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>A brief introduction to XenBus from the perspective of the driver</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/18/4278532.aspx</link><pubDate>Thu, 18 Jun 2009 10:09:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/18/4278532.aspx</guid><description>Writing Xen Drivers: Using XenBus and XenStore&lt;br /&gt;&lt;br /&gt;XenBus
provides a bus abstraction for paravirtualized drivers to communicate
between domains. In practice, the bus is used for configuration
negotiation, leaving most data transfer to be done via an interdomain
channel composed of a shared page and an event channel. &lt;br /&gt;&lt;br /&gt;
 Xenstore is a centralized
configuration database that is accessible by all domains. Management
tools configure and control virtual devices by writing val&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4278532.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>Utilize OpenSolaris beadm to test unstable bits</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/17/4277082.aspx</link><pubDate>Wed, 17 Jun 2009 17:05:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/17/4277082.aspx</guid><description>&lt;br /&gt;If you need to test an dev kernel binarie. Try the following best practice.&lt;br /&gt;&lt;br /&gt;
One thing you can do is to use beadm(1M) to create one or more alternate boot  environments (BE). This way you can keep 2009.06 but also experiment with the newer&lt;br /&gt;
bits in the dev tree.&lt;br /&gt;&lt;br /&gt;
There are various ways to do this... This is what I usually do to ensure that the stock bits remained absolutely unchanged. What we'll do it to create a tree of cloned disk images..&lt;br /&gt;&lt;br /&gt;
Creat&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4277082.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>Physical device interrupt handling in XEN</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/17/4276500.aspx</link><pubDate>Wed, 17 Jun 2009 14:38:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/17/4276500.aspx</guid><description>&lt;br /&gt;In Xen, only the Hypervisor has an access to the
hardware so that to achieve isolation (it is dangerous to share the
hardware and let other domains access directly hardware devices
simultaneously). &lt;br /&gt;Let's take a little walkthrough dealing with Xen interrupts: &lt;br /&gt;Handling
interrupts in Xen is done by using event channels. Each domain can hold
up to 1024 events. An event channel can have 2 flags associated with it
: pending and mask. The mask flag can be updated only by guests.&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4276500.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>how to prevent ZFS from eating too much memory</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/16/4273495.aspx</link><pubDate>Tue, 16 Jun 2009 15:28:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/16/4273495.aspx</guid><description>&lt;br /&gt;See this guide:http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Limiting_the_ARC_Cache This syntax is provided starting in the Solaris 10 8/07 release and Nevada 
(build 51) release. &lt;br /&gt;For example, if an application needs 5 GBytes of memory on a system with 
36-GBytes of memory, you could set the arc maximum to 30 GBytes, (0x780000000 or 
32212254720 bytes). Set the zfs:zfs_arc_max parameter in the /etc/system file: 
&lt;br /&gt;set zfs:zfs_arc_max = 0x780000000 &lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4273495.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>Best Practice to Set OpenSolaris 200906 as xvm domain 0</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/16/4273445.aspx</link><pubDate>Tue, 16 Jun 2009 15:15:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/16/4273445.aspx</guid><description>&lt;br /&gt;See this blog:&lt;br /&gt;&lt;br /&gt; http://blogs.sun.com/levon/entry/opensolaris_2008_11_as_a1&lt;br /&gt;&lt;br /&gt;But you should add a limit to dom0_mem on the kernel line in the&lt;br /&gt;grub menu.lst entry... e.g.&lt;br /&gt;&lt;br /&gt; title xvm&lt;br /&gt; findroot (pool_rpool,0,a)&lt;br /&gt; bootfs rpool/ROOT/xvm&lt;br /&gt; kernel$ /boot/$ISADIR/xen.gz dom0_mem=2g&lt;br /&gt; module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=text&lt;br /&gt; module$ /platform/i86pc/$ISADIR/boot_archive&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4273445.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>How domain 0 works on xen hypervisor</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/16/4273353.aspx</link><pubDate>Tue, 16 Jun 2009 14:49:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/16/4273353.aspx</guid><description>&lt;br /&gt;A tour of the Mini-OS kernel
Satya Popuri&lt;br /&gt;Graduate Student&lt;br /&gt;University of Illinois at Chicago&lt;br /&gt;Chicago, IL 60607&lt;br /&gt;spopur2 [at] uic [dot] edu&lt;br /&gt;Introduction
Mini-OS is a small OS kernel distributed with the Xen hypervisor sources. I have documented some of the basic parts of this kernel for the reference of people trying to port their OSes to Xen (also for people writing new OSes for Xen). This work is not completed yet. The present document includes a discussion of in&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4273353.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>Allen Lu</dc:creator><title>Xen Memory Management</title><link>http://blog.csdn.net/hotsolaris/archive/2009/06/12/4264019.aspx</link><pubDate>Fri, 12 Jun 2009 15:28:00 GMT</pubDate><guid>http://blog.csdn.net/hotsolaris/archive/2009/06/12/4264019.aspx</guid><description>&lt;br /&gt;Below was cited from https://wiki.cs.dartmouth.edu/nihal/doku.php/xen:memory. Changes subject to this site.&lt;br /&gt;&lt;br /&gt;All low-level memory operations go through Xen.Guest OSes are responsible for allocating and initializing PTs for processes (restricted to read only access)allocates and initialize a page and register it with Xen to serve as the new PTDirect page writes are intercepted, validated and applied by the Xen VMMupdate can be batched into a single hypercall (reduce cost of enter&lt;img src ="http://blog.csdn.net/hotsolaris/aggbug/4264019.aspx" width = "1" height = "1" /&gt;</description></item></channel></rss>