Thanks, Zhongyuan.
I have what I need to update the spec now. It will be updated by the
time you get in tomorrow (or COB Monday PST).
Thanks,
Jack
zhongyuan sun - Sun Microsystems - Beijing China wrote:
> Hi Jack,
>
> ?2009?12?19??04:41?Jack Schwartz???
>
>> Hi Zhongyuan.
>>
>> On 12/17/09 22:20, zhongyuan sun - Sun Microsystems - Beijing China
>> wrote:
>>
>>> Looks good! a little clarification,
>>>
>>> ?2009?12?18??08:17?Jack Schwartz???
>>>
>>>
>>>> Hi Zhongyuan.
>>>>
>>>> Thanks for your feedback.
>>>>
>>>> On 12/16/09 22:45, zhongyuan sun - Sun Microsystems - Beijing China
>>>> wrote:
>>>>
>>>>
>>>>> Hi Jack,
>>>>>
>>>>> Thanks your quick response. my comments:
>>>>>
>>>>> (1)I'm not very clear about class devscan_data, what its main function?
>>>>> so far I think it's no more different with a list type. The main
>>>>> scanning function was implemented by ddu_devscan(). If devscan_data only
>>>>> provide like append function, I suggest just use a list but not this
>>>>> additional class.
>>>>>
>>>>>
>>>>>
>>>> The devscan_data class bundles the data with search functionality. (I
>>>> assume this search functionality is something you need, since you had
>>>> originally suggested using a dictionary.)
>>>> get_list_by_devtype(devtype) is the search method.
>>>> A list by itself could be used, but then you would need to add
>>>> external search methods to filter the data, (like all devices of type
>>>> "Audio"). It is convenient to put those methods into the same class
>>>> as the data.
>>>>
>>>>
>>> ddu_devscan function will be used in GUI/AI/Text-mode parts.
>>> While in GUI part, ddu_devscan will be called separately for each
>>> components(audio,network,storage....), the source code would be
>>> like:ddu_devcan(return_missing_only=All, device_type="audio") and then
>>> ddu_devcan(return_missing_only=All, device_type="network") and on. In
>>> this way, ddu_devscan will do the search method, its return value(will
>>> be stored in class devscan_data) do not need to search again.
>>> For AI/Text-mode parts, ddu_devscan will be called only once and return
>>> all missing driver components. But since AI/Text-mode do not care about
>>> which type(audio,network...) the devices belongs to, so in this way even
>>> class devscan_data provide get_list_by_devtype method, it will never be
>>> called.
>>> In a summary, I do not know when this method get_list_by_devtype in
>>> class devscan_data will be called.
>>>
>>>
>> Thanks for your clarification. So get_list_by_devtype() is not
>> needed, and we can just use a list at the top level.
>>
>> ddu_devscan() will now return a list of dev_data objects.
>>
> It's OK, Thanks.
>
>
>
>>>
>>>
>>>> Why my class instead of a dictionary? Because it is simpler and more
>>>> flexible than a dictionary. This class is flexible as you can add
>>>> additional search methods in the future if needed.) If a dictionary
>>>> is used instead then this additional flexibility becomes harder to
>>>> implement. I would think (but haven't verified this) that
>>>> dictionaries are more heavyweight than the dev_data class.
>>>>
>>>>
>>>>> (2)Which class will in charge of store "Device compatible name" string
>>>>> used by ddu_package_lookup()? I did not put it in class dev_data because
>>>>> I think this class only store general device information, while "Device
>>>>> compatible name" is not a general information especially for that device
>>>>> which already has a working driver. "Device compatible name" will be
>>>>> only useful for fetching driver information. Shall we add a new function
>>>>> to generate "Device compatible name"? This function's argument can be
>>>>> pci path and output is "Device compatible name".
>>>>>
>>>>>
>>>>>
>>>> From what I see, dev_data stores data specific to a device. (For
>>>> example, attach_status and instance_ID are very specific to a
>>>> device.) The compatible name string is another piece of device
>>>> specific data, and so I think we should include it in dev_data.
>>>> (Note: it is currently missing from dev_data; that is an oversight
>>>> and will be corrected.)
>>>>
>>>>
>>>>
>>> Yes, compatible name string could be a property of class dev_data. While
>>> from the implementation point of view, all the current dev_data 11
>>> properties(description,driver_name,instance_ID...) are get from one
>>> session(they are output from a DDU tool). We do not include compatible
>>> name string as a default output because its only useful for missing
>>> driver components. For that non-missing driver component DDU does not
>>> use it. So for most devices the compatible name string is not a very
>>> critical property for DDU, DDU only fetch it when needed that is a
>>> missing driver device want to look for its driver.
>>> Of course DDU can get compatible name string very easy, but it need some
>>> more codes in another block. That why i suggest to create another method
>>> in dev_data.
>>> Again the dev_data 11
>>> properties(description,driver_name,instance_ID...)are get from one
>>> session and compatible name string will be fetched from another session
>>> even if the method is very easy.
>>> If compatible name string is a property of class dev_data, From
>>> performance point of view, the non-missing driver device will set it to
>>> None and missing driver device will set to its real value?
>>>
>>>
>> A specification assumes (and therefore limits) the use of a field when
>> it specifies that field is to be set only under certain conditions.
>> This is not always a bad thing, but a more versatile solution is to
>> always set the field if it is going to be present. So I suggest to
>> either always set the compatible name or else to not include it in the
>> structure.
>>
>> Let's take the suggestion you made yesterday, and have a separate
>> function to return the compatible name string, when given a dev_data
>> object argument. This way, the DDU can get the compatible name when
>> it needs it (and so performance around this will be optimized), and
>> dev_data fields will be consistent.
>>
> Or you can put this function as a method of dev_data, while either
> solution is OK, thanks.
>
>
>
>> How about this:
>>
>> def get_compatible_name(dev_data):
>> # Returns compatible name string
>>
>>
>>>> If the compatible name string is in dev_data, do you still need the
>>>> vendor_id, device_id and class_code? (I think you do, as you can use
>>>> these items to locate a specific kind of device if necessary, but
>>>> please confirm.)
>>>>
>>>>
>>> Yes
>>>
>>>
>> OK.
>>
>>>
>>>
>>>> You can already retrieve a device's compatible name string from the
>>>> kernel via prtconf (and probably other ways too). Since the device
>>>> compatible name string is already generated elsewhere, let's not
>>>> create another function to generate it again. Duplication of existing
>>>> functionality makes the code more difficult to maintain.
>>>>
>>>>
>>>>> (3)function ddu_devscan() and ddu_package_lookup() will take a little
>>>>> long time when it running, also during this time these two functions
>>>>> will fork some child processes. Should we provide a mechanism to stop
>>>>> these functions during it running then they can kill all their child
>>>>> processes? This situation usually happens in GUI environment.
>>>>>
>>>>>
>>>>>
>>>> I think providing a way for the parent to kill its child processes is
>>>> a good idea. However, I would try to make it automatic via a signal
>>>> handler. When the parent receives a signal to die, have it catch that
>>>> catch and process its signal by signaling each of its children to die
>>>> gracefully before terminating itself.
>>>>
>>>>
>>> This is exactly what i want, all the child process will be killed via
>>> signal. I just want a way for these two functions ddu_devscan() and
>>> ddu_package_lookup() can send kill signals to their child processes. For
>>> example, can we set a argument for these functions? If the function
>>> found this argument has been set to True, then they can have a chance to
>>> send kill signals to child processes.
>>>
>>>
>> I think what you are suggesting is that ddu_devscan and
>> ddu_package_lookup will spawn subprocesses when called with an
>> argument "termination=False" and to kill the subprocesses they spawned
>> when called with "termination=True". Do I understand correctly?
>>
>> Assuming I understand correctly, I don't think the additional arg is
>> necessary. Just have their parent (whoever calls ddu_devcscan and
>> ddu_package_lookup) send a signal to the process group at termination
>> time. This will terminate those subprocesses plus all of their
>> children. If you don't want to terminate the parent at that time, set
>> it up to ignore the signal before sending it.
>>
>>
> Thanks, this way make things simple.
>
>
>
>> I wrote and attached a sample shell and python program to show how
>> this can be done. You may need to do a hybrid approach of the two
>> programs depending on how your library is set up.
>>
>> Since we seem to be converging, I'm going to update the spec again.
>> If you have more issues or if I didn't understand you correctly,
>> please reply ASAP.
>>
>> Thanks,
>> Jack
>>
>> P.S. Don't use these sample programs as examples of final form.
>> Though they are reasonably clean, I haven't checked them for PEP8
>> compliance or style conformity, etc.
>>
>>> Thanks,
>>> Zhongyuan
>>>
>>>
>>>> Thanks,
>>>> Jack
>>>>
>>>>
>>>>> Also thanks Keith's review, I agree with his comments.
>>>>>
>>>>> Thank,
>>>>> Zhongyuan
>>>>>
>>>>> ?2009?12?17??07:02?Jack Schwartz???
>>>>>
>>>>>
>>>>>
>>>>>> Hi Zhongyuan.
>>>>>>
>>>>>> Thanks for your feedback. Here's my assessment of requirements, based
>>>>>> on both of our emails, and a new proposal which I believe addresses
>>>>>> both
>>>>>> of our needs and concerns. Hopefully it is not too long...
>>>>>>
>>>>>> A) You need a way to easily restrict the output to a given device
>>>>>> type.
>>>>>> I assume this why you proposed a dictionary keyed to the device type,
>>>>>> at the top level. I didn't account for that in my original proposal.
>>>>>>
>>>>>> B) My proposal placed more of an emphasis on readability and clarity.
>>>>>> This is why I originally proposed to store a device's attributes in a
>>>>>> dictionary: attributes could be extracted by name.
>>>>>>
>>>>>> Additional requirements, as I see things:
>>>>>>
>>>>>> C) We don't want to make the data structures too complicated from a
>>>>>> data
>>>>>> access perspective. For example a dictionary of lists of dictionaries
>>>>>> makes the code hard to follow.
>>>>>>
>>>>>> D) We don't want to introduce unnecessary overhead. If we can use
>>>>>> something more lightweight than a dictionary and still have the
>>>>>> functionality we need, then I would favor not using the dictionary.
>>>>>>
>>>>>>
>>>>>> ddu_devscan() will be returning a group of items corresponding to
>>>>>> devices, so it is appropriate to use a collection of some kind for the
>>>>>> top level data structure it returns. At first I agreed with you that
>>>>>> a
>>>>>> dictionary would be best at the top level:
>>>>>> - its items are named (via a key),
>>>>>> - it can filter out unwanted items,
>>>>>> - it doesn't have to keep a place for items it doesn't need.
>>>>>> However, after thinking more, this could prove restrictive in the
>>>>>> future. We return lots of information for each device, any of which
>>>>>> could potentially be used as a filter for returning data. If the
>>>>>> dictionary is keyed on device type and later we decide we need to
>>>>>> filter on something else (or perhaps multiple items), say vendor ID
>>>>>> and/or device ID, we're not set up for that.
>>>>>>
>>>>>> Instead, I propose a new class, call it devscan_data, which stores the
>>>>>> full list of items returned by ddu_devscan() and has a method for
>>>>>> searching and returning only items of a particular device type. Then
>>>>>> in the future we could add other methods to support returning items
>>>>>> based on some other filter criteria. It is also lightweight and
>>>>>> provides only the functionality needed.
>>>>>>
>>>>>> What are the devscan_data list items? They would store the different
>>>>>> fields of data per device. The list could point to dictionaries as I
>>>>>> had originally proposed, to tuples as you have proposed, or to
>>>>>> something
>>>>>> else. I have changed my mind about dictionaries, and think they are
>>>>>> the
>>>>>> wrong tool; the number and type of fields will not change from one
>>>>>> device to the next. I also still don't like tuples as the fields are
>>>>>> hard to keep track of. Named tuples are better, but more heavyweight
>>>>>> than if we defined a new class to hold the data. So I propose a new
>>>>>> class, which would have attributes and get() methods for each field we
>>>>>> want to return. Let's call it dev_data for now.
>>>>>>
>>>>>> To summarize:
>>>>>>
>>>>>> ddu_devscan() would return a devscan_data object defined like this:
>>>>>>
>>>>>> class devscan_data():
>>>>>>
>>>>>> def __init__()
>>>>>> # Holds objects of dev_data.
>>>>>> self.dev_data_list = []
>>>>>>
>>>>>> def add_dev_data_object(dev_data):
>>>>>> self.dev_data_list.append(dev_data)
>>>>>>
>>>>>> def get_list_by_devtype(device_type):
>>>>>> # loop through instance list data to find and return matches
>>>>>> on
>>>>>> # device_type
>>>>>>
>>>>>> Lists returned by get_list_by_devtype() point to objects of type
>>>>>> dev_data.
>>>>>> There is one of these objects per device returned.
>>>>>>
>>>>>> class dev_data:
>>>>>>
>>>>>> def __init__(...):
>>>>>> self.device_type = ...
>>>>>> self.description = ...
>>>>>> self.driver_name
>>>>>> self.instance_ID
>>>>>> self.item_ID
>>>>>> self.parent_item_ID
>>>>>> self.attach_status
>>>>>> self.vendor_id
>>>>>> self.device_id
>>>>>> self.class_code
>>>>>> self.pci_path
>>>>>>
>>>>>> def get_device_type():
>>>>>> return self.device_type
>>>>>>
>>>>>> def get_description():
>>>>>> return self.description
>>>>>>
>>>>>> ...
>>>>>> ...
>>>>>>
>>>>>> def get_pci_path:
>>>>>> return self.pci_path
>>>>>>
>>>>>> Does this work for you?
>>>>>>
>>>>>> Thanks,
>>>>>> Jack
>>>>>>
>>>>>> On 12/15/09 21:56, zhongyuan sun - Sun Microsystems - Beijing China
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Jack,
>>>>>>>
>>>>>>> It's OK ddu_devscan return dictionary type instead of a list of tuples.
>>>>>>> I suggest use device type as this dictionary's key and the dictionary's
>>>>>>> value would be a list of tuples.
>>>>>>>
>>>>>>> ddu_devscan description would be as following:
>>>>>>>
>>>>>>> Arguments:
>>>>>>> - return_missing_only: Boolean; default value is True
>>>>>>> - When True, ddu_devscan returns only the devices which are missing
>>>>>>> drivers.
>>>>>>> - When False, all devices found are returned.
>>>>>>> - device_type: Type of devices to scan for. "All" to check all.
>>>>>>> - Possible types
>>>>>>> are:"audio"/"battery"/"cpu"/"cd_dvd"/"memory"/"network"/"storage"/"usb"/"video"/"others"
>>>>>>>
>>>>>>>
>>>>>>> In each tuple of the list:
>>>>>>> - ItemID:
>>>>>>> - Parent Item ID:
>>>>>>> /*these two fields(ItemID and Parent Item ID) used for device
>>>>>>> tree to
>>>>>>> identify a device and the controller it attached to. Of
>>>>>>> course for a
>>>>>>> controller we do not need to set its parent Item ID.
>>>>>>> */
>>>>>>> - Device description:Device name
>>>>>>> - Device ID:
>>>>>>> - Classcode:
>>>>>>> - PCI physical path:This field used to get its detail information.
>>>>>>> - Driver name:
>>>>>>> - Instance ID:
>>>>>>> - Attachment status:
>>>>>>> /*These two fields(Instance ID and Attachment status) used for
>>>>>>> determine whether a driver
>>>>>>> has been attached abnormally.
>>>>>>> */
>>>>>>> - Vendor ID
>>>>>>>
>>>>>>>
>>>>>>> Here is a short example of ddu_devscan return value:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> {'Audio': [(200,"","nVidia Corporation MCP55 High Definition
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> Audio","0x0371","00040300","[0,6,1]","unknown",-1,"Detached","0x10de")],'Network':[(0,"","nVidia
>>>>>>> Corporation MCP55
>>>>>>> Ethernet","0x0373","00068000","[80,8,0]","nge",0,"Attached","0x10de"),(1,"","nVidia
>>>>>>> Corporation MCP55
>>>>>>> Ethernet","0x0373","00068000","[80,9,0]","nge",1,"Attached","0x10de")],'DVD':[(400,"","nVidia
>>>>>>> Corporation MCP55
>>>>>>> IDE","0x036e","0001018a","[0,4,0]","pci-ide",0,"Attached","0x10de"),(401,400,"MATSHITA
>>>>>>> DVD-RAM UJ-85JS","","","/pci at 0,0/pci-ide at 4/ide at 0/sd at
>>>>>>> 0,0","sd",0,"Attached","")]}
>>>>>>>
>>>>>>>
>>>>>>> I also would like to discuss with you a issue during scan process. When
>>>>>>> user kill GUI during scan process, some backround scripts will still be
>>>>>>> running even GUI thread has been killed, these scripts was created when
>>>>>>> performing scanning. Our solution was send a SIGUSR2 signal when GUI
>>>>>>> want to kill its child processes. While if we wrapped our scripts into
>>>>>>> ddu_devscan, how can this function send a signal to its child processes?
>>>>>>> can we add a argument for this?
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Zhongyuan
>>>>>>>
>>>>>>> ?2009?12?15??06:43?Jack Schwartz???
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Zhongyuan.
>>>>>>>>
>>>>>>>> Thanks for reviewing the interface spec. Moving to public forum.
>>>>>>>>
>>>>>>>> > I've some comments on DDU library API--ddu_devscan() function.
>>>>>>>> > You've expanded this function to involve all devices found, it's
>>>>>>>> > good! While for the Return value, currently it only includes
>>>>>>>> > "compatible name" and "device descriptor" strings, It's not
>>>>>>>> > sufficient especially for GUI part:
>>>>>>>> >
>>>>>>>> > *For non-mission items
>>>>>>>> > (1)If the driver works fine,we need a "driver name" field.
>>>>>>>> >
>>>>>>>> OK
>>>>>>>>
>>>>>>>> > (2)If the driver dos not works fine, wee need the driver instance
>>>>>>>> > ID and attachment status for this driver.
>>>>>>>> >
>>>>>>>> > Instance ID is a number get from system when driver attached. If
>>>>>>>> > you have 2 e1000g nic cards and they all have been attached
>>>>>>>> > properly, then they will get instance 0 and 1, while if the driver
>>>>>>>> > have not been attached properly or device have been installed
>>>>>>>> > properly, the instance ID will be <0 and attachment status will be
>>>>>>>> > "detached".
>>>>>>>> >
>>>>>>>> > DDU GUI version used "instance ID" and attachment status to give
>>>>>>>> > user a notification "driver missconfigured".
>>>>>>>>
>>>>>>>> OK
>>>>>>>>
>>>>>>>> >
>>>>>>>> > BTW, for both non-missing and missing device, I hope we can add
>>>>>>>> > "device category" argument to ddu_devscan function to indicate what
>>>>>>>> > type of category will be looked for(like "Audio"/"Network" etc). By
>>>>>>>> > default this argument can be set to "All" to look for all types of
>>>>>>>> >
>>>>>>>> device.
>>>>>>>>
>>>>>>>> OK.
>>>>>>>>
>>>>>>>> > For both missing and non-missing items, we also need these fields
>>>>>>>> > at least:
>>>>>>>> > (1)"Vendor id"/"device id"/"classcode" to identify which category
>>>>>>>> > this device belongs to.
>>>>>>>>
>>>>>>>> OK.
>>>>>>>>
>>>>>>>> > (2)pci path to indicate this device's detail information.
>>>>>>>> > Hopefully this can be involved into ddu_devscan function.
>>>>>>>>
>>>>>>>> OK.
>>>>>>>>
>>>>>>>> These are a lot of changes for ddu_devscan() for the GUI. I propose
>>>>>>>> that ddu_devscan returns a list of dictionaries rather than a list of
>>>>>>>> tuples (as before). Dictionaries because there are a lot of items
>>>>>>>> returned. Also, not all fields will be used for all devices. (For
>>>>>>>> example, the driver_name field won't be used when a device is missing).
>>>>>>>>
>>>>>>>> So this would translate into adding a signature of ddu_devscan() as
>>>>>>>> follows:
>>>>>>>>
>>>>>>>> Arguments:
>>>>>>>> - return_missing_only: Boolean; default value is True
>>>>>>>> - When True, ddu_devscan returns only the devices which are missing
>>>>>>>> drivers.
>>>>>>>> - When False, all devices found are returned.
>>>>>>>> - device_type: Type of devices to scan for. "All" to check all.
>>>>>>>>
>>>>>>>> ===> Please send the list of device types which are valid. "Audio"
>>>>>>>> and
>>>>>>>> "Network" were mentioned earlier.
>>>>>>>>
>>>>>>>> Returns:
>>>>>>>> A list of dictionaries, each dictionary representing a device. List
>>>>>>>> can
>>>>>>>> be empty (possible only when Return_missing_only is True) to represent
>>>>>>>> a
>>>>>>>> system with no missing drivers.
>>>>>>>>
>>>>>>>> Items in each dictionary are:
>>>>>>>>
>>>>>>>> - compatible: device compatible name string, a space-separated string
>>>>>>>> of
>>>>>>>> all compatible names for a device. Compatible names in the string are
>>>>>>>> ordered from the most specific name to the most general name (i.e. the
>>>>>>>> "pciclass" definitions are listed last).
>>>>>>>> - It is OK if two list items have one or more compatible
>>>>>>>> names in common, but each list item should be unique.
>>>>>>>>
>>>>>>>> - description: Device description. can be used for error messages and
>>>>>>>> status reporting.
>>>>>>>>
>>>>>>>> - device_type: Type of device (e.g. "Audio", "Network")
>>>>>>>>
>>>>>>>> - driver_name: Name of the driver operating the device. (Can be
>>>>>>>> omitted
>>>>>>>> if driver is missing.)
>>>>>>>>
>>>>>>>> - instance_ID: Instance ID assigned to the device. (Always present.
>>>>>>>> Will be <0 if no driver is attached to the device.)
>>>>>>>>
>>>>>>>> - attach_status: Status of whether or not a driver is attached to the
>>>>>>>> device. (Always present. Will be "detached" if driver is not
>>>>>>>> attached,
>>>>>>>> "attached" if driver is attached.
>>>>>>>>
>>>>>>>> ===> Any other statuses possible?
>>>>>>>>
>>>>>>>> - vendor_id: Device's vendor ID. (Always present.)
>>>>>>>>
>>>>>>>> - device_id: Device's device ID (Always present.)
>>>>>>>>
>>>>>>>> - class_code: Device's class code (Always present.)
>>>>>>>>
>>>>>>>> - pci_path: Device path (Always present.)
>>>>>>>>
>>>>>>>> Please let me know by today COB (PRC time) the device types and if any
>>>>>>>> corrections are needed.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jack
>>>>>>>>
>>>>>>>> On 12/04/09 09:20, Jack Schwartz wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi everyone.
>>>>>>>>>
>>>>>>>>> FYI: Driver Update functional and programming interface specs have
>>>>>>>>> had
>>>>>>>>> a minor update. The items addressed deal either with subtleties
>>>>>>>>> missed during the main review but which came up during development,
>>>>>>>>> or
>>>>>>>>> other things we discovered were needed during development.
>>>>>>>>>
>>>>>>>>> Functional spec:
>>>>>>>>> - Clarify that any repo can be specified, not only repos which a
>>>>>>>>> system already
>>>>>>>>> knows about.
>>>>>>>>> - Clarify that it is an error if a publisher name is already mapped
>>>>>>>>> to
>>>>>>>>> a repo,
>>>>>>>>> and another repo with the same publisher name is requested.
>>>>>>>>> - Add publisher to AI searchall capability
>>>>>>>>>
>>>>>>>>> Interface spec:
>>>>>>>>> - Add arg to ddu_devscan() so that the function can return either all
>>>>>>>>> devices
>>>>>>>>> on a system, or only devices which are missing their driver.
>>>>>>>>>
>>>>>>>>> Links on the Driver Update page have been updated. Previous spec
>>>>>>>>> versions have been retained on that page for comparison purposes.
>>>>>>>>>
>>>>>>>>> Driver update page is at:
>>>>>>>>> http://hub.opensolaris.org/bin/view/Project+caiman/Driver_Update
>>>>>>>>>
>>>>>>>>> If there are any questions or comments please send them my way.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Jack
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>> ______________________________________________________________________
>> #!/bin/ksh
>>
>> #
>> # Child part
>> #
>> if [ "$1" == "child" ] ; then
>> $0 grandchild &
>> $0 grandchild &
>> echo "Hi from child with pid $$"
>> sleep 1000
>> echo "Bye from child with pid $$"
>> exit 0
>> fi
>>
>> #
>> # Grandchild part
>> #
>> if [ "$1" == "grandchild" ] ; then
>> echo "Hi from grandchild with pid $$"
>> sleep 1000
>> echo "Bye from grandchild with pid $$"
>> exit 0
>> fi
>>
>> #
>> # Parent part
>> #
>>
>> #---------------
>> function handler
>> #---------------
>> {
>> echo "Terminating all child processes in this group ($$)..."
>>
>> # Catch the signal we're about to send out, so that I don't terminate by it.
>> # Needed to prevent recursion if this handler is called when TERM received
>> # (see "trap handler" line in main below)
>> trap "" TERM
>>
>> # Send out the signal.
>> pkill -TERM -g $$
>>
>> # Now perform any other cleanup I have to do.
>> echo "Check for un-killed children..."
>> echo "There should be only this process with PID $$ showing..."
>> ps -efjl | head -1
>> ps -efjl | grep $$ | grep -v grep | grep -v efjl
>> echo "Handler Bye from parent"
>> exit 0
>> }
>>
>> #-----
>> # Main
>> #-----
>>
>> # Catch ^C, ^\ and regular "kill"
>> trap handler INT QUIT TERM
>>
>> # Call this script with "child" as first arg to spawn child processes
>> $0 child &
>> $0 child &
>> sleep 1000
>> echo "Normal Bye from parent" # This won't execute if handler
>> terminates me.
>> exit 0
>>
>> ______________________________________________________________________
>> #!/bin/python2.6
>>
>> import sys
>> import subprocess
>> import os
>> import signal
>> import time
>>
>> from subprocess import PIPE as PIPE
>>
>> #--------------------------
>> def handler(signum, frame):
>> #--------------------------
>> print ("Terminating all child processes in this group (" +
>> str(os.getpid()) + ") ...")
>>
>> # Catch the signal we're about to send out, so that I don't terminate by
>> it.
>> # Needed to prevent recursion if this handler is called when TERM
>> received
>> # (see "trap handler" line in main below)
>> signal.signal(signal.SIGTERM, signal.SIG_IGN)
>>
>> # Send out the signal.
>> subprocess.Popen(["/bin/pkill", "-TERM", "-g", str(os.getpid())])
>>
>> # Now perform any other cleanup I have to do.
>> print "Check for un-killed children..."
>> print ("There should be only this process with PID " +
>> str(os.getpid()) + " showing...")
>> # subprocess.Popen(["/bin/ps", "-efjl", "|", "head", "-1", ";",
>> # "/bin/ps", "-efjl", "|", "grep", str(os.getpid()),
>> "|",
>> # "grep", "-v", "grep", "|", "grep", "-v", "efjl"],
>> # shell=True)
>> p1 = subprocess.Popen(["/bin/ps", "-efjl"], stdout=PIPE)
>> p2 = subprocess.Popen(["head", "-1"], stdin=p1.stdout)
>> p2.wait()
>> p1 = subprocess.Popen(["/bin/ps", "-efjl"], stdout=PIPE)
>> p2 = subprocess.Popen(["grep", str(os.getpid())], stdin=p1.stdout,
>> stdout=PIPE)
>> p3 = subprocess.Popen(["grep", "-v", "grep"], stdin=p2.stdout,
>> stdout=PIPE)
>> p4 = subprocess.Popen(["grep", "-v", "efjl"], stdin=p3.stdout)
>> p4.wait()
>> print "Handler Bye from parent"
>> sys.exit(0)
>>
>>
>> #--------------
>> def main(argv):
>> #--------------
>> full_pathname = os.getcwd() + "/" + argv[0].rsplit("/",1)[1]
>>
>> #
>> # Child part
>> #
>> if ((len(argv) > 1) and (argv[1] == "child")):
>> subprocess.Popen([full_pathname, "grandchild"])
>> subprocess.Popen([full_pathname, "grandchild"])
>> print "Hi from child with pid " + str(os.getpid())
>> time.sleep(1000)
>> print "Bye from child with pid " + str(os.getpid())
>> sys.exit(0)
>>
>> #
>> # Grandchild part
>> #
>> if ((len(argv) > 1) and (argv[1] == "grandchild")):
>> print "Hi from grandchild with pid " + str(os.getpid())
>> time.sleep(1000)
>> print "Bye from grandchild with pid " + str(os.getpid())
>> sys.exit(0)
>>
>> #
>> # Parent part
>> #
>>
>> # Catch ^C, ^\ and regular "kill"
>> signal.signal(signal.SIGINT, handler)
>> signal.signal(signal.SIGQUIT, handler)
>> signal.signal(signal.SIGTERM, handler)
>>
>> # Call this script with "child" as first arg to spawn child processes
>> subprocess.Popen([full_pathname, "child"])
>> subprocess.Popen([full_pathname, "child"])
>> time.sleep(1000)
>> print "Normal Bye from parent" # This won't execute if handler
>> terminates me
>> sys.exit(0)
>>
>> if __name__ == "__main__":
>>
>> try:
>> main(sys.argv)
>> except (SystemExit, KeyboardInterrupt):
>> pass
>>
>>
>
>
