MoonOcean

Main | Next page »
Tuesday Jun 24, 2008

How should I do to block garbage comments ?

I am really boring to delete hundreds garbage comments (advertisements, baleful jokes etc.) manually. Who would teach me how to block them?

Friday May 23, 2008

Stand-alone version of Sun Device Detection Tool 2.1 is available.

Sun Device Detection Tool is also available as a stand-alone version. The stand-alone version does not require an internet access to run as it includes the built-in driver data. Its features are same as that of the version available on the web site

Currently, the stand-alone version of Sun Device Detection Tool 2.1 is available at here. Download the binary package; copy it to any Solaris, Linux, Windows or Mac machine even without internet access; unpack it; and execute the corresponding script under ddtool_21_loc directory. You will get the Solaris driver availability report for the machine.

Wednesday May 21, 2008

Login OpenSolaris 2008.05 as *root* user

When you install the OpenSolaris 2008.05, there is page prompting you to input the root password along with creating a normal user. If you define a normal user at that time, you will find that you are not allowed to login the system with root user. 

What should you do? Re-install the system? It is a solution. But there is a much easier one as follows:

Revise the following line in the file of /etc/user_attr

----------------------

root::::type=role;auths=solaris.*,solaris.grant;profiles=All;lock_after_retries=no;min_label=admin_low;clearance=admin_high 

----------------------

to

----------------------

root::::auths=solaris.*,solaris.grant;profiles=All;lock_after_retries=no;min_label=admin_low;clearance=admin_high

----------------------

And then reboot the system. You can login as root again.

*^^*

 

Wednesday May 14, 2008

Sun Device Detection Tool 2.1 source code is available on OpenSolaris.org

Source code of Sun Device Detection Tool 2.1 is open sourced at OpenSolaris.org (http://www.opensolaris.org/os/project/ddtool/ddtool-2.1-src.tar.gz).

The tool is a Java application, and builds a JNI binding for each of the following interfaces to collect device information on mutiple platforms:

OS
Interface
Solution 
Solaris OS
libdevinfo
Looking up PCI nodes in prom tree and reading device data from the nodes
Windows OS
Win32 API  
Reading device data from registry through Win32 API
Linux OS
/proc/bus/pci Scanning the file of /proc/bus/pci and reading device data from it 
Mac OS X IOPCIDevice Collecting PCI Device Information

Thanks a lot for Tony Hu's hard work of developing native programs for Solaris, Windows, Linux and Mac platforms to scan PCI devices.

Reference:

Device Detection Tool product web page:
http://www.sun.com/bigadmin/hcl/hcts/device_detect.jsp
Device Detection Tool open project web page: http://www.opensolaris.org/os/project/ddtool/
Device Detection Tool developer blog: http://blogs.sun.com/moonocean/
Device Detection Tool support alias: device-detect-feedback@sun.com

Help you to determine if OpenSolaris 2008.05 can be installed on your x86/x64 system

Sun Device Detection Tool 2.1 provides driver information for OpenSolaris 2008.05 now. You can check the OpenSolaris 2008.05 driver availability status for the PCI devices on your x86/x64 systems.

http://www.sun.com/bigadmin/hcl/hcts/device_detect.jsp

:-)
 

Wednesday May 07, 2008

Sun Device Detection Tool will provide driver information for OpenSolaris 2008.05

OpenSolaris 2008.05 is released. We can expect that much more people want to try it. Providing users the Solaris driver availability information for their devices before downloading the OpenSolaris image would be helpful for many people.

Sun Device Detection Tool will provide driver information for OpenSolaris 2008.05 in few days. The OpenSolaris driver db is coming ...



Monday May 05, 2008

Run a jar file with ant

Ant is a very useful tool. We can use it to compile, package jar files, and run the packaged jar.  Following is example to describe how to write the build.xml file to run a packaged jar file with ant.

The jar file's name is ddtool.jar, and the main class of it is com.sun.ddtool.manager.DDToolManager. If the jar file is executed manually in CLI mode, the running command will be as follows:

$ java -classpath ./lib/commons-codec-1.3.jar:./lib/commons-httpclient-3.0.1.jar:./lib/commons-logging-1.1.jar:./ddtool.jar -Djava.library.path=lib com.sun.ddtool.manager.DDToolManager http://129.158.218.41 DriverDB/ dblocation.xml.zip

NOTE: "http://129.158.218.41", "DriverDB/", and "dblocation.xml.zip" are 3 arguments passed to the main class.

In the build.xml, we can describe it like this:

<!--class path-->
 <path id="execute-classpath">
  <fileset dir="${dist.bin.dir}/">
   <include name="ddtool.jar"/>
  </fileset>
  <fileset dir="${lib.dir}/">
   <include name="*.jar"/>
  </fileset>
 </path>

<!--run-->
  <target name="execute" depends="packjar" description="run the project">    
     <java classname="com.sun.ddtool.manager.DDToolManager" failonerror="true" fork="true">
       <classpath refid="execute-classpath"/>
       <sysproperty key="java.library.path" value="lib/"/> 
       <arg value="http://129.158.218.41"/>
       <arg value="DriverDB/"/>   
       <arg value="dblocation.xml.zip"/>
     </java>    
  </target>

Or, if you don't want to define the execute-classpath, the above targets could be replaced by the following one:
  <target name="execute" depends="packjar" description="run the project">
     <exec executable="java">
       <arg line="-classpath ${dist.lib.dir}/commons-httpclient-3.0.1.jar:${dist.lib.dir}/commons-codec-1.3.jar:${dist.lib.dir}/commons-logging-1.1.jar:${dist.bin.dir}/ddtool_21.jar  -Djava.library.path=${dist.lib.dir} com.sun.ddtool.manager.DDToolManager http://129.158.218.41 DriverDB/ dblocation.xml.zip"/>
     </exec>
  </target>


NOTE: "${dist.lib.dir}/commons-httpclient-3.0.1.jar:${dist.lib.dir}/commons-codec-1.3.jar:${dist.lib.dir}/commons-logging-1.1.jar" in the second example cannot be replaced with "${dist.lib.dir}/*.jar".

Friday Apr 25, 2008

Detect PCI devices on Mac OS X

On Mac OS, PCI device object could be enumerated with the 'IOPCIDevice' service. Then PCI device information could be retrieved from object properties.

To detect PCI devices on Mac OS X, the following interface needs to be imported:

OS TypeInterfacePurpose 
Mac OS XIOPCIDevice
Collecting PCI Device Information

Sun Device Detection Tool 2.1 is released.

Sun Device Detection Tool 2.1 has been released since April 18, 2008. It is accessible from http://www.sun.com/bigadmin/hcl/hcts/device_detect.html

What's new of SDDTool 2.1:

1. Support Mac OS for device detection. 

2. Display the device data (vendor id, device id, class code etc.) of each detected PCI device in Solaris driver availability report.

3. Collect add-in patch info, and attached driver name of each detected PCI device automatically along with other system configuration information on Solaris OS.

4. Enable users to save the HCL submission report in HTML format on Solaris OS.

5. Provide the driver db for latest Solaris 10 and Solaris Express Developer Edition release.

 



 

Monday Mar 24, 2008

Make Indiana and SNV parallel systems on a single machine

I planed to install a latest snv and an indiana on a single hard disk firstly. However, it failed, since it seems that the Indiana occupied a whole hard disk defaultly.

What I found are two IDE disks. So I changed to install the Indiana on the master disk, and install snv_85 on the secondary one. What I did are listed as follows:

[1] Install Indiana on the master disk (c0d0).

The process is very simple. You have no choice to custom the disk space. Everything is finished by few clicking.

[2] Install the latest SNV (snv_85) on the secondary disk (c0d1).

You need to chose "custom install" rather than "default install", and set c0d1 as the only disk to be layout Indiana filesystem. When you deselect the c0d0, a message will appear to reminder you to reset BIOS after installation. In my experience, the message could be ignored totally.

[3] Reboot and enter the Indiana.

[4] Mount c0d1 to /mnt and copy the content of /mnt/boot/grub/menu.lst to append to the file of /rpool/boot/grub/menu.lst.

The menu.lst file of Indiana is as follows:

==================================================== 
splashimage /boot/grub/splash.xpm.gz
timeout 30
default 0

title OpenSolaris Developer Preview 2 snv_79b X86
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
module$ /platform/i86pc/$ISADIR/boot_archive

title Solaris Express Community Edition snv_85 X86
kernel$ /platform/i86pc/kernel/$ISADIR/unix
module$ /platform/i86pc/$ISADIR/boot_archive

title Solaris xVM
kernel$ /boot/$ISADIR/xen.gz
module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix
module$ /platform/i86pc/$ISADIR/boot_archive

title Solaris failsafe
kernel /boot/platform/i86pc/kernel/unix -s
module /boot/x86.miniroot-safe

====================================================

[5] Reboot again. There are really 4 entries displayed in the grub menu while booting. I selected the second one to enter snv_85. What happened then? The system didn't enter snv_85, but returned to the grub menu. There must be something wrong with the menu.lst.

[6] I forgot to set the root commands in menu.lst. Added them as follows:

===================================================
splashimage /boot/grub/splash.xpm.gz
timeout 30
default 0

title OpenSolaris Developer Preview 2 snv_79b X86
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
module$ /platform/i86pc/$ISADIR/boot_archive

title Solaris Express Community Edition snv_85 X86
root (hd1,0,a)
kernel$ /platform/i86pc/kernel/$ISADIR/unix
module$ /platform/i86pc/$ISADIR/boot_archive

title Solaris xVM
root (hd1,0,a)
kernel$ /boot/$ISADIR/xen.gz
module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix
module$ /platform/i86pc/$ISADIR/boot_archive

title Solaris failsafe
root (hd1,0,a)
kernel /boot/platform/i86pc/kernel/unix -s
module /boot/x86.miniroot-safe

===================================================

NOTE: The root entry has the following format (hdx,x,x) where the first entry in the tuple is the disk identifier, the second entry is the partition number (0-3), and the third entry is the slice number (a-h), where a is slice 0 and h is slice 7. The root command is not needed if your boot environment is on the disk slice given to the installgrub command (such as the Indiana slice).

[7] Reboot and entry any system you want.


 

Tuesday Mar 18, 2008

How does Sun Device Detection Tool work?

Sun Device Detection Tool is a device driver detection tool which helps users to make sure their component drivers are available on Solaris OS before adoption. It is a cross-platform utility working on Solaris, Windows and Linux OS (Mac OS is coming).

In a certain aspect, Sun Device Detection Tool is a 'predict' tool. It could predict whether those devices in you Windows or Linux system work when a Solaris OS is installed on the machine.

How does it do that? It is actually simple:
    
[1] Sun Device Detection Tool collects device data of PCI devices in users' systems.
[2] The tool compares the detected device data with a Solaris driver database which is maintained by Sun to check the Solaris driver availability status for each device.
[3] The tool generates a Solaris driver availability report to show users.

How does it collect device data of users' PCI devices?

Sun Device Detection Tool 1.0
gets the device information by running specific system commands respectively on Solaris, Linux and Windows OS as follows, and parses the output message of system commands to extract device information such as vendor id, device id, etc..

OS
System Command
Utility
Solaris OS
prtconf -pv prtconf
Windows OS reg query hklm\system\currentcontrolset\enum\pci /s register.exe
Linux OS
lspci -vv -n PCIUtilities


For this reason, Sun Device Detection Tool 1.0 depends on the availability and robustness of above system commands, and their output message format.

Sun Device Detection Tool 2.0 enhances the device data collecting method. It imports following interfaces to collect device information:

OS
Interface
Solution 
Solaris OS
libdevinfo
Looking up PCI nodes in prom tree and reading device data from the nodes
Windows OS
Win32 API  
Reading device data from registry through Win32 API
Linux OS
/proc/bus/pci Scanning the file of /proc/bus/pci and reading device data from it 

Sun Device Detection Tool 2.0 is a Java application, it builds a JNI binding for each of the interfaces to collect device information. The enhancement frees it from dependence of system commands.

Sun Device Detection Tool 2.0 also allows device information to be feed into it from plain text files that contain the output message of system commands listed in the first table. The received device information is scanned and parsed by Sun Device Detection Tool 2.0 to extract device data (as what Sun Device Detection Tool 1.0 did). This function enables the users to check the Solaris driver availability status for remote machines or those without Internet access.

Thursday Mar 06, 2008

Sun Device Detection Tool is open source.

Sun Device Detection Tool is a device driver detection tool which helps users to determine whether their PCI devices are supported by Solaris OS.

To its history, please refer to

The Path to Sun Device Detection Tool

The first version of Sun Device Detection Tool (1.0) was released on Oct. 26, 2006. This is its web site: http://www.sun.com/bigadmin/hcl/hcts/device_detect.jsp. The latest update of it is 2.0.

The source code of Sun Device Detection Tool 2.0 is finally released. It is available at
http://www.opensolaris.org/os/project/ddtool/ddtool-2.0-src.tar.gz. The web site of the open source project is http://www.opensolaris.org/os/project/ddtool/.

 

Friday Feb 22, 2008

Change properties of Java ToolTip (background, border, etc.)

Sun UIRB commitee requires that ToolTips should have a yellow background color (#fff7c8), with a black or dark grey (#4c4f53) border, and the ToolTip should be showed for 15 seconds. 

To change such properties, there is a very simple way by adding a few lines of code (see below) where the ToolTip is referenced:

-----------------------------

 UIManager.put("ToolTip.background", new ColorUIResource(255, 247, 200)); // The color is #fff7c8.
 Border border = BorderFactory.createLineBorder(new Color(76,79,83)); // The color is #4c4f53.
 UIManager.put("ToolTip.border", border);
 ToolTipManager.sharedInstance().setDismissDelay(15000);// 15 seconds    

 setToolTipText(message); // The message is a String variable containing text to display.

-----------------------------

If more properties of the ToolTip are required to be changed, or the changed ToolTip needs to be referenced multiple times in the program, it is better to create a Look&Feel class as follows:

----------------------------------

/**
* DemoFrame.java
* This test frame is to demonstrate changing of tooltip background
*/

import javax.swing.*;
import javax.swing.text.*;
import java.awt.*;
import java.awt.event.*;

import javax.swing.plaf.metal.MetalLookAndFeel;
import javax.swing.plaf.ColorUIResource;
import javax.swing.border.Border;

class ToolTipLookAndFeel extends MetalLookAndFeel
{
    protected void initSystemColorDefaults(UIDefaults table)
    {       
        super.initSystemColorDefaults(table);       
        table.put("info", new ColorUIResource(255, 247, 200));   
    }

    protected void initComponentDefaults(UIDefaults table) {
        super.initComponentDefaults(table);

    Border border = BorderFactory.createLineBorder(new Color(76,79,83));
    table.put("ToolTip.border", border);
    }
}


public class DemoFrame extends JFrame
{
    public DemoFrame()
    {
        super("Demo");

        try {                             
            UIManager.setLookAndFeel(new ToolTipLookAndFeel());
        } catch(Exception ex) {       
            System.err.println("ToolTipLookAndFeel exception!");
            System.err.println(ex.getMessage());
        }

        getContentPane().setLayout(new FlowLayout());

        JButton btn = new JButton("<html>Mouse Over me <br> for ToolTip </html>");               
       
        btn.setToolTipText("<html>I have changed <br> the color of <br> background and border. <br> It works! </html>");

        getContentPane().add(btn);

        JLabel label = new JLabel("What about me");
        label.setToolTipText("Me Too...");

        getContentPane().add(label);
    }

    public static void main(String[] arg)
    {
        DemoFrame m = new DemoFrame();

        m.setVisible(true);
        m.setSize(new Dimension(300, 150));
        m.validate();
    }

----------------------------------

Save the above code into a single java file, compile it, and run the DemoFrame class.

Note: If the following line of

    UIManager.setLookAndFeel(new ToolTipLookAndFeel());

is changed to

    UIManager.setLookAndFeel("ToolTipLookAndFeel");

the code of ToolTipLookAndFeel class must be moved to a separated file instead of being a internal class in the DemoFrame.java file. And the ToolTipLookAndFeel.java must be compiled before DemoFrame.java file.
Otherwise, the ToolTipLookAndFeel class cannot be really reference, the exception will be catched without any error or warning message while compiling. It is a little tricky.





 

Tuesday Dec 04, 2007

Is it a bug of Java Web Start?

I hava a Java application which is deployed by JavaWS. And a shared objected is deployed as a native library of the application. (Following is a piece of the JNLP file.)


<resources>
<j2se version="1.4+" java-vm-args="-client"/>
<jar href="/foo.jar" main="true" download="eager"/>
<nativelib href="/libfoo.jar"/>
</resources>


Theoretically, when the application launches, all jar files have been loaded on users' system. And the application should work, even if the network cable is plugged out.

When I tested the application with JRE 1.4.2 and 1.5, it actually worked after launching without network access.

However, when I tried it with JRE 1.6, the application fails. It seems that the application cannot load the shared object.

I am sure that I run the application with JRE1.4.2, 1.5 and 1.6 on the same machine. Each time before I tested it, the Java cache (/.java directory) is cleaned. So I can say that the shared library did not exist on the box for testing 1.4.2 and 1.5.

Is it a bug of JavaWS?

Wednesday Nov 28, 2007

A simple example of JNI

Java Native Interface (JNI) is a standard programming interface for writing Java native methods and embedding the JVM into native applications. Simply, it is a Java technology with which a Java application can call a method written with such as C, C++ and assembly.

Adopting JNI is very simple. You need two components -- a Java program, and a native library. The native library is written in other languages and compiled on corresonding platforms.

A function defined in the native library should be declared in Java code as a 'native' function. And the native library needs to be load in Java code with the System.loadLibrary method. The natvie function could be referced by other regular functions in the Java code.

Following is an example of the Java Code.

JNIFoo.java
===========

public class JNIFoo {    
    public native String nativeFoo();    

    static {
        System.loadLibrary("foo");
    }        

    public void print () {
    String str = nativeFoo();
    System.out.println(str);
    }
    
    public static void main(String[] args) {
    (new JNIFoo()).print();
    return;
    }
}

# javac JNIFoo.java
# javah -jni JNIFoo

A file named as JNIFoo.h is created by running the above two commands. A function of 'JNIEXPORT jstring JNICALL Java_JNIFoo_nativeFoo  (JNIEnv *, jobject)' is in the JNIFoo.h file. The function must be implemented in a source code file (e.g. a C file), and it is the actually entry to do what the funtion of natvieFoo() in Java code do.


foo.c
======

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <jni.h>
#include "JNIFoo.h"

JNIEXPORT jstring JNICALL Java_JNIFoo_nativeFoo (JNIEnv *env, jobject obj)
{
  int i;
  int ds_ret;

  char* newstring;

  jstring ret = 0;

  newstring = (char*)malloc(30);

  if(newstring == NULL)
  {     
      return ret;
  }

  memset(newstring, 0, 30); 
 
  newstring = "foo: Test program of JNI.\n";
  

  ret = (*env)->NewStringUTF(env, newstring);

  free(newstring);

  return ret;
}

JNI libraries are named with the library name used in the System.loadLibrary method of your Java code with a prefix and a suffix. On different OS, the prefix and suffix might be different.

On Solaris OS, it is prefixed by 'lib' and suffixed with '.so'

# cc -Kpic -G -o libfoo.so -I/usr/java/include -I/usr/java/include/solaris foo.c -z text

On Linux OS, it is prefixed by 'lib' and suffixed with '.so'.

# gcc -shared -fpic -o libfoo.so -I/usr/java/include -I/usr/java/include/linux foo.c

On Windows OS, it is prefixed by nothing and suffixed with '.dll'.
It could be compiled with Visual Studio automatically and create a file named as foo.dll.

On Mac OS, it is prefixed by 'lib' and suffixed with '.jnilib'.

# gcc -dynamiclib -o libfoo.jnilib -I/System/Library/Frameworks/JavaVM.framework/Headers foo.c -framework JavaVM

 

To run the JNI program locally, the following command is fine:

# java -Djava.library.path=<path_of_native_lib> JNIFoo