WO2001046801A1

WO2001046801A1 - A method and system for providing support between multiple applications and serial bus devices

Info

Publication number: WO2001046801A1
Application number: PCT/US2000/041449
Authority: WO
Inventors: Michael J. Berkovec; Sheng Dong
Original assignee: Sony Electronics, Inc.
Priority date: 1999-10-21
Filing date: 2000-10-19
Publication date: 2001-06-28
Also published as: AU5441901A

Abstract

A method and system for providing support between multiple applications and IEEE 1394 devices. Specifically, one embodiment is a software layer (e.g., running on a host computer system) which acts as a server (600) for applications (630, 640) to communicate with the devices (620a, 620b) coupled to IEEE 1394 bus. The software server keeps track of allocation of resources (610a, 610b) by device, such as allocated addresses. As such, when an application tries to allocate a resource, the software server first refers to an allocation look-up table in order to determine whether the specified resource is already allocated. It should be appreciated that the allocation look-up table contains information which was stored as a result of previous allocations. If the specified resource is allocated (found by the software server in the allocation look-up table), then the shared resource is subsequently made available and used by the application. If the specified resource is not allocated, then an allocation takes place and the resource is noted within the allocation look-up table before being used by the application. The server (600) thereby facilitates device usage by removing contention over the device between a first (630) and a second application (640).

Description

A METHOD AND SYSTEM FOR PROVIDING SUPPORT BETWEEN MULTIPLE APPLICATIONS AND SERIAL BUS DEVICES

BACKGROUND

TECHNICAL FIELD

The present invention relates to the field of the IEEE 1394 serial communication bus architecture. More specifically, the present invention relates to the field of multiple applications accessing a device coupled to the IEEE 1394 bus.

RELATED ART

Computers have become an integral tool used in a wide variety of different applications, such as in finance and commercial transactions, computer-aided design and manufacturing, health care, telecommunication, education, etc. Computers are finding new applications as a result of advances in hardware technology and rapid development in software technology. Furthermore, a computer system's functionality is dramatically enhanced by coupling a stand-alone computer to other functional devices. e.g., digital video disc (DVD) players, printers, video cameras, scanners, video cassette recorders (VCRs), and other computers. It should be appreciated that there are several different ways to communicatively couple these type of electronic devices to a computer system.

One popular way to communicatively couple electronic devices to a computer system is to use an Institute of Electrical and Electronics Engineers (IEEE) 1394 serial communication bus architecture. The IEEE 1394 standard is an international standard for implementing an inexpensive high-speed serial bus architecture which supports both asynchronous and isochronous format data transfers. The IEEE 1394 standard provides a high-speed serial bus for interconnecting digital devices thereby providing universal input/output connection. The IEEE 1394 standard defines a digital interface for applications thereby eliminating the need for an application to covert digital data to an analog form before it is transmitted across the bus. Correspondingly, a receiving application will receive digital data from the bus, not analog data, and will therefore not be required to convert analog data to digital form. The IEEE 1394 standard is ideal for consumer electronics communication in part because devices can be added to or removed from the serial bus while the bus is active. If a device is so added or removed, the bus automatically reconfigures itself for transmitting data between the then existing devices. Each device on the bus is a "node" and contains its own address space.

It should be appreciated that typical operating systems (running on a computer system which is coupled to an IEEE 1394 bus) create a device driver for each device coupled to the IEEE 1394 bus. In order to communicate with a device coupled to the IEEE 1394 bus, an application running on the computer system opens that device's corresponding device driver. Before the device driver can be used, it is first "installed" within the system, e.g., by allocating system resources to the device driver. Also, conventional systems only provide a driver interface that applications can use to communicate directly with the device. This situation creates problems when multiple applications (running on a same system) need to communicate with a same IEEE 1394 device which is coupled to an IEEE 1394 bus attached to the system. In order for multiple applications of a same system to concurrently access the same device, the applications typically need to know what the other applications are doing with that device, otherwise, problems may occur. For example, assume a first application performs an allocation of an address space for a device driver for a given device. Then, subsequently, a second application attempts to allocate the same device driver without knowledge that the device driver has already been allocated for that same device. In this case, the second attempt will fail even though the device has its address space allocated (by the first application). This result shuts the second application out from accessing the device. Another undesirable scenario would be that the second application succeeds in allocating the address space, and the two applications compete for the asynchronous command notifications, perhaps taking notification data away from each other. These problems are often compounded after an IEEE 1394 bus reset in which all device driver allocations are lost incident to the bus reset and need to be re-established. One solution to the above problem is to have each application be aware of what the other applications (of the same system) are doing with respect to the IEEE 1394 bus. However, there are disadvantages associated with the applications knowing what other applications are doing while concurrently accessing the same device. One of the main disadvantages is that additional complex software code is typically implemented within each application in order to perform this functionality, thereby increasing the complexity and expense of each application's software code. Another disadvantage is that various applications can be made by different venders. The applications made by different vender may not be compatible, thereby making it very difficult to allow applications to know what other applications are doing. Further, for secuπty reasons, it may be desirable for an application to perform its activities specifically without other applications knowing of those activities.

SUMMARY

Accordingly, a need exists for a method and system for enabling multiple applications (of a same host system) to access a shared device coupled to an IEEE 1394 serial communication bus without implementing additional complex software code within each application.

The present invention provides a method and system for enabling multiple applications to access a shared device coupled to an IEEE 1394 serial communication bus without implementing additional complex software code within each application. One embodiment of the present invention involves a software layer (e.g., running on a host computer system) that acts as a server for applications to communicate with the devices coupled to the IEEE 1394 bus. In accordance with the present invention, when an application wants to make a call to the device object, it calls a function in the software server, and the software server does any necessary bookkeeping before calling to the device driver. By creating this client/server approach within the present embodiment, it allows the software layer to keep details hidden from the application, as well as share information or data across applications without an application having to be aware of other applications.

Specifically, the software server of the present embodiment keeps track of allocation of resources by device, such as allocated addresses. As such, when a requesting application tries to allocate a resource, the software server first refers to an allocation look-up table in order to determine whether the specified resource is already allocated (e.g., by another application). It should be appreciated that the allocation look-up table contains information which was stored as a result of previous allocations. If the specified resource is already allocated (found by the software server in the allocation look-up table), then the shared resource is made available for use by the requesting application. If the specified resource is not allocated, then an allocation takes place and the resource is noted within the allocation look-up table before being used by the application. The server maintains a count of the number of clients (applications) that have allocated a resource on the IEEE 1394 device. When a resource is freed by an application, the server decrements the associated count. If the count becomes zero, the resource is no longer being used by any applications, and the resource actually located for the device is released. In another embodiment, the present invention is a method for enabling a plurality of applications to access a shared device coupled to a serial communication bus. The method includes the step of a first application requesting allocation of a resource for the shared device. Furthermore, the method includes the step of allocating the resource of a host computer for use by a device driver interfaced to the shared device. The method also includes the step of sending a resource handle to the first application indicating that the resource is allocated to the first application. Additionally, the method includes the step of a second application requesting allocation of the resource. Moreover, the method includes the step of sending the resource handle to the second application to enable the first application and the second application to access the shared device coupled to the serial communication bus and interfaced to the device driver.

In still another embodiment, the present invention includes a computer readable medium having computer readable code embodied therein for causing a computer to perform particular steps. Specifically, one of the steps is a first application requesting allocation of a resource for a shared device. Furthermore, another one of the steps is allocating the resource of the computer for use by a device driver interfaced to the shared device. Another one of the steps is sending a resource handle to the first application indicating the resource is allocated to the first application. Moreover, one of the steps is a second application requesting allocation of the resource. Additionally, one of the steps is sending the resource handle to the second application to enable the first application and the second application to access the shared device coupled to a serial communication bus and interfaced to the device driver. In still yet another embodiment, the present invention includes a computer system which includes a processor which is coupled to an addressable data bus. The computer system also includes a computer readable memory coupled to communicate with the processor for performing the steps of a method for enabling a first application and a second application to access a shared device coupled to a serial communication bus. The method includes the step of the first application requesting allocation of a resource for the shared device. Additionally, the method includes the step of allocating the resource of the computer system for use by a device driver interfaced to the shared device. Furthermore, the method includes the step of sending a resource handle to the first application indicating the resource is allocated to the first application. The method also includes the step of the second application requesting allocation of the resource. Moreover, the method includes the step of sending the resource handle to the second application to enable the first application and the second application to access the shared device coupled to the serial communication bus and interfaced to the device driver.

These and other aspects of the present invention will become obvious to those of ordinary skill in the art after having read the following detailed description of the preferred embodiments which are illustrated in the drawing figures.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention:

Figure 1 is a block diagram of an exemplary computer system upon which embodiments of the present invention may be implemented.

Figure 2 illustrates an exemplary networked system of electronic devices coupled to a computer system using IEEE 1394 serial communication bus cables. Figure 3 is a flowchart of steps performed in accordance with one embodiment of the present invention for enabling multiple applications to access a shared device coupled to an IEEE 1394 serial communication bus.

Figure 4 is a flowchart of steps performed in accordance with one embodiment of the present invention for releasing an allocated resource of a shared device when all applications are finished using the shared device.

Figure 5 is a flowchart of steps performed in accordance with one embodiment of the present invention for reallocating resources listed within an allocation look-up table to their corresponding applications after an IEEE 1394 serial communication bus reset occurs. Figure 6 illustrates a data flow diagram in accordance with an embodiment of the present invention including the server, device objects and application requests. DETAILED DESCRIPTION

Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be obvious to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention. Some portions of the detailed descriptions which follow are presented in terms of procedures, logic blocks, processing, and other symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. In the present application, a procedure, logic block, process, etc., is conceived to be a self- consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. It has proved convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as "requesting", "allocating", "sending", "tracking", "receiving", "storing", "transmitting", "reallocating" or the like, refer to the actions and processes of a computer system, or similar electronic computing device. The computer system or similar electronic computing device manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission, or display devices. The present invention is also well suited to the use of other computer systems such as, for example, optical and mechanical computers.

COMPUTER SYSTEM ENVIRONMENT

With reference now to Figure 1 , portions of the present method and system are comprised of computer-readable and computer-executable instructions which reside, for example, in computer-usable media of a computer system. Figure 1 illustrates an exemplary computer system 100 used to perform the present invention. It is appreciated that system 100 of Figure 1 is only exemplary and that the present invention can operate within a number of different computer systems including general purpose networked computer systems, embedded computer systems, stand alone computer systems, and the like. System 100 of Figure 1 includes an address/data bus 102 for communicating information, and a central processor unit 104 coupled to bus 102 for processing information and instructions. Central processor unit 104 may be an 80x86-family microprocessor or any other type of processor. System 100 also includes data storage features such as a computer usable volatile memory 106 (e.g., random access memory, static RAM, dynamic RAM, etc.) coupled to bus 102 for storing information and instructions for central processor unit 104, computer usable non-volatile memory unit 108 (e.g., read only memory, programmable ROM, flash memory, EPROM, EEPROM, etc.) coupled to bus 102 for storing static information and instructions for the central processor unit 104, and a data storage unit 110 (e.g., a magnetic or optical disk and disk drive) coupled to bus 102 for storing information and instructions. System 100 of the present invention also includes an optional alphanumeric input device 112, which includes alphanumeric and function keys, is coupled to bus 102 for communicating information and command selections to central processor unit 104. System 100 also optionally includes a cursor control device 114 coupled to bus 102 for communicating user input information and command selections to central processor unit 104. System 100 of the present embodiment also includes an optional display device 116 coupled to bus 102 for displaying information. Referring still to Figure 1 , optional display device 1 16 may be a liquid crystal device, cathode ray tube, or other display device suitable for creating graphic images and alphanumeric characters recognizable to a user. Optional cursor control device 1 14 allows the computer user to dynamically signal the two dimensional movement of a visible symbol (e.g., cursor) on a display screen of display device 116. Many implementations of cursor control device 1 14 are known in the art including a mouse, trackball, touch pad, joystick or special keys on alphanumeric input device 112 capable of signaling movement of a given direction or manner of displacement. Alternatively, it is appreciated that a cursor can be directed and/or activated via input from alphanumeric input device 112 using special keys and key sequence commands. The present invention is also well suited to directing a cursor by other means such as, for example, voice commands. Computer system 100 also includes a signal generating device 118 coupled to bus 102 for interfacing with other networked devices over an Institute of Electrical and Electronics Engineers (IEEE) 1394 serial communication bus 207.

Referring now to Figure 2, which illustrates an exemplary network system 200 in which an embodiment in accordance with the present invention operates. Exemplary network system 200 includes consumer electronic devices and computer system 100 as nodes, but could be extended equally well to cover other electronic devices. Exemplary system 200 includes a video cassette recorder (VCR) 202, a television set (TV) 204, and computer system 100 connected together by IEEE 1394 serial communication bus cables 206 and 208. The IEEE 1394 cable 206 couples VCR 202 to computer system 100 allowing VCR 202 to send data, commands, and parameters to computer system 100 for display (or to any other device of network 200). Conversely, IEEE 1394 cable 206 allows computer system 100 to send data, commands, and parameters to VCR 202. Computer system 100 is also coupled to TV 204 by IEEE 1394 cable 208. It should be recognized that data, commands, and parameters can be sent between all of the devices within IEEE 1394 network 200. It is appreciated that the present invention can reside within a computer system or any intelligent device embedded within any of the nodes (devices) of the IEEE 1394 serial communication bus.

The IEEE 1394 serial bus 207 used by system 200 is a high-speed bus architecture for interconnecting digital devices thereby providing a universal input/output connection. The IEEE 1394 standard defines a digital interface for the applications thereby eliminating the need for an application to covert digital data to analog data before it is transmitted across the bus. Correspondingly, a receiving application receives digital data from the bus, not analog data, and therefore is not required to covert analog data to digital data. The cable required by the IEEE 1394 standard is very thin in size compared to other bulkier cables used to connect such devices. Devices can be added and removed from an IEEE 1394 bus while the bus is active. If a device is so added or removed, the IEEE 1394 bus automatically reconfigures itself for transmitting data between the then existing nodes. A node is considered a logical entity having a unique address on the bus structure. It should be appreciated that the IEEE 1394 serial communication bus architecture is well known by those of ordinary skill in the art.

DETAILED DESCRIPTION OF THE STRUCTURE AND ITS OPERATION With reference to Figure 3, which is a flowchart 300 of steps performed in accordance with one embodiment of the present invention for enabling a plurality of applications to access a shared device coupled to an IEEE 1394 serial communication bus. Flowchart 300 includes processes of the present invention which, in one embodiment, are carried out by a processor and electrical components under the control of computer readable and computer executable instructions. The computer readable and computer executable instructions reside, for example, in data storage features such as computer usable volatile memory 106 and/or computer usable non- volatile memory 108 of Figure 1. Although specific steps are disclosed in flowchart 300, such steps are exemplary. That is, the present invention is well suited to performing various other steps or variations of the steps recited in Figure 3. It should be appreciated that the steps of flowchart 300 can be performed by software or hardware or any combination of software and hardware. In general, as described within the flowchart 300, the present invention provides a software layer (e.g., running on computer system 100) which acts as a server for applications to communicate with the devices coupled to the IEEE 1394 serial communication bus. This layer allows applications to have some knowledge of the previous allocations done by other applications without requiring any special code or logic (within each application) for tracking the actions of other applications.

Specifically, the software server keeps track of allocation of resources by device, such as allocated addresses. As such, when an application tries to allocate a resource, the software server first refers to an allocation look-up table in order to determine whether the specified resource is already allocated. It should be appreciated that the allocation look-up table contains information which was stored as a result of previous allocations. If the specified resource is allocated (found by the software server in the allocation look-up table), then the shared resource is subsequently made available to the application for use by the application. If the specified resource is not allocated, then an allocation takes place and the resource is noted within the allocation look-up table before being used by the application.

It should be appreciated that for the present embodiment to operate properly, applications should communicate directly with the server software for allocation of resources and not with any device drivers. As such, the applications of the present embodiment use an application program interface (API) in order to facilitate communication with the server software.

In step 302 of Figure 3, the present embodiment determines whether an application has requested allocation of a resource for a shared device (e.g., VCR 202 of Figure 2) coupled to the IEEE 1394 serial communication bus. At step 302, if the present embodiment determines that an application has not requested allocation of a resource for a shared device coupled to the IEEE 1394 bus, the present embodiment proceeds to the beginning of step 302. However, if the present embodiment determines at step 302 that an application has requested allocation of a resource for a shared device coupled to the IEEE 1394 bus, the present embodiment proceeds to step 304. In one example, a requested allocation is an allocation of memory space for a device driver associated with an IEEE 1394 device. In another example, the allocation requests are made directly to the server of the present invention which becomes aware of the request upon receipt of the request. At step 304, the present embodiment determines whether the specified resource has already been allocated. It should be application that the present embodiment performs this determination of step 304 by using a memory stored allocation look-up table. The allocation look-up table of the present embodiment contains information corresponding to resources which have been previously allocated. For example, some of the information that is stored within the allocation look-up table of the present embodiment is a name of a shared device along with its corresponding resource handle (e.g., a pointer). If the present embodiment determines at step 304 that the specified resource has already been allocated, the present embodiment proceeds to step 314. Conversely, if the present embodiment determines at step 304 that the specified resource has not been allocated, the present embodiment proceeds to step 306.

In step 306 of Figure 3, the present embodiment requests allocation from a device driver (also referred to as a device object) corresponding to the shared device. At step 308, upon receiving the allocation request, the device driver of the present embodiment returns a resource handle. It should be appreciated that resource handles .are well known by those of ordinary skill in the art. In step 310, upon receiving the resource handle, the present embodiment stores it within the allocation look-up table together with the name of the shared device. At step 312, the present embodiment increases an allocation counter by one. It should be appreciated that for each allocated resource within the present embodiment, there is a corresponding allocation counter value. Furthermore, each allocation counter value is stored within the allocation look-up table together with its corresponding allocated resource. In step 314, the present embodiment sends the a copy of the resource handle to the application. Upon receiving the resource handle, the application believes (in terms of allocation) it has exclusive access to the shared device. The requesting application can now use the handle to access the resources as if the resources were allocated just for the application's sole use. The resources can be used, in one example, for a device driver so that the requesting application can access a device (e.g., IEEE 1394 device) associated with the device driver. Upon completion of step 314, the present embodiment proceeds to the beginning of step 302. It is appreciated that Figure 6 illustrates a data flow diagram corresponding to one example of the above functionality for a server 600 that contains two resources allocations for two IEEE 1394 devices. It is appreciated that an exemplary code example for allocation is shown further below.

Referring now to Figure 4, which is a flowchart 400 of steps performed in accordance with one embodiment of the present invention for releasing an allocated resource of a shared device when all applications are finished using the shared device. Flowchart 400 includes processes of the present invention which, in one embodiment, are carried out by a processor and electrical components under the control of computer readable and computer executable instructions. The computer readable and computer executable instructions reside, for example, in data storage features such as computer usable volatile memory 106 and/or computer usable nonvolatile memory 108 of Figure 1. Although specific steps are disclosed in flowchart 400, such steps are exemplary. That is, the present invention is well suited to performing various other steps or variations of the steps recited in Figure 4. It should be appreciated that the steps of flowchart 400 can be performed by software or hardware or any combination of software and hardware.

The general idea of the present embodiment of flowchart 400 is to release an allocated resource of a shared device when all applications are finished using the shared device. In other words, flowchart 400 basically performs the opposite functionality of that performed by flowchart 300 of Figure 3. Furthermore, flowchart 400 of the present embodiment operates in conjunction with flowchart 300 of Figure 3. A counter can be used, in one implementation, to track the number of applications that are currently using an allocated resource. In step 402 of Figure 4, the present embodiment determines whether a free signal has been received from an application that is using an allocated resource for a shared device (e.g., VCR 202 of Figure 2). Within the present embodiment, a free signal is a resource handle which was previously issued to the application during an allocation process (e.g., flowchart 300). If the present embodiment determines at step 402 that a free signal has not been received from an application, the present embodiment proceeds to the beginning of step 402. However, if the present embodiment determines at step 402 that a free signal has been received from an application, the present embodiment proceeds to step 404.

At step 404, for the resource specified by the received resource handle, the present embodiment decrements its corresponding allocation counter value by one, which is stored within an allocation look-up table. It should be appreciated that the allocation counter value and allocation look-up table of the present embodiment have the same functionality as the ones described above with reference to Figure 3. In step 406 of Figure 4, the present embodiment determines whether the allocation count value of the specified resource is equal to zero. At step 406, if the present embodiment determines the allocation count value of the specified resource is not equal to zero, the present embodiment proceeds to the beginning of step 402. Conversely, if the present embodiment determines at step 406 that the allocation count value of the specified resource is equal to zero, the present embodiment proceeds to step 408. In step 408, the present embodiment sends a release signal to a device driver corresponding to the specified resource. Upon receiving the release signal, the device driver releases the allocated resource. Upon completion of step 408, the present embodiment proceeds to step 402. It is appreciated that an exemplary code example for deallocation is shown further below.

Referring to Figure 5, which is a flowchart 500 of steps performed in accordance with one embodiment of the present invention for reallocating resources listed within an allocation look-up table to their corresponding applications after an IEEE 1394 serial communication bus reset occurs. The allocation look-up table of the present embodiment operates in a similar manner as the one described above with reference to Figure 3. Flowchart 500 includes processes of the present invention which, in one embodiment, are carried out by a processor and electrical components under the control of computer readable and computer executable instructions. The computer readable and computer executable instructions reside, for example, in data storage features such as computer usable volatile memory 106 and/or computer usable nonvolatile memory 108 of Figure 1. Although specific steps are disclosed in flowchart 500, such steps are exemplary. That is, the present invention is well suited to performing various other steps or variations of the steps recited in Figure 5. It should be appreciated that the steps of flowchart 500 can be performed by software or hardware or any combination of software and hardware.

As mentioned above, when an IEEE 1394 bus reset occurs, the general idea of the present embodiment of flowchart 500 is to reallocate the resources listed within an allocation look-up table to their corresponding applications. It should be appreciated that flowchart 500 of the present embodiment operates in conjunction with flowchart 300 of Figure 3 and flowchart 400 of Figure 4.

In step 502 of Figure 5, the present embodiment determines whether an IEEE 1394 serial communication bus reset has occurred. At step 502, if the present embodiment determines an IEEE 1394 bus reset has not occurred, the present embodiment proceeds to the beginning of step 502. However, if the present embodiment determines at step 502 that an IEEE 1394 bus reset has occurred, the present embodiment proceeds to step 504. At step 504, the present embodiment reallocates all allocated resources which were listed within the allocation look-up table (as described above with reference to Figure 3) to their corresponding applications. It should be appreciated that the present embodiment performs step 504 without the applications knowing about it. In step 506, the present embodiment notifies the client applications that a bus reset occurred so that they can make use of that information. Upon completion of step 506, the present embodiment proceeds to step 502.

Figure 6 illustrates a data flow diagram 670 in accordance with an embodiment of the present invention including the server 600 of the present invention, device objects (drivers) 620a and 620b and applications 630 and 640. In the exemplary state of Figure 6, the server 600 contains two allocations, a first allocation of resources 610a for device driver 620a and a second allocation of resources 610b for device driver 620b. Device driver 620a is for a first IEEE 1394 device and device driver 620b is for a second IEEE 1394 device. The server 600 contains at least two entries within its lookup table (allocation table), e.g., a first entry for associating resources 610a for the first device and a second entry for associating resources 610b for the second device. Resources 610a were allocated originally based on a request from application 630. As shown in Figure 6, when application 640 requests allocation for the first device, the request is processed by the server 600 which determines that resources (610a) are already allocated for the first device. Therefore, the server 600 returns the resources 610a for use by the second application.

CODE EXAMPLE Although the present invention can be implemented using a number of different programming languages and techniques, one code example is given below for an allocation and for a deallocation of a resource:

AllocateResource (Resource resource) { if (allocation_count (resource) ==0 ) allocate (resource) ; allocation_count (resource) ++ ; }

DeallocateResource (Resource resource) { allocation_count (resource) -- ; if (allocation_coun (resource) ==0) release (resource) ; }

Thus, one embodiment in accordance with the present invention provides a method and system for enabling multiple applications to access a shared device coupled to an IEEE 1394 serial communication bus without implementing additional complex software code within each application.

The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the Claims appended hereto and their equivalents.

Claims

CLAIMSWhat is claimed is:

1. A method for enabling a plurality of applications to access a shared device coupled to a serial communication bus comprising the steps of: a) a first application requesting allocation of a resource of an intelligent device for said shared device; b) allocating said resource for use by a device driver interfaced to said shared device; c) sending a resource handle to said first application indicating said resource is allocated to said first application; d) a second application requesting allocation of a resource for said shared device; and e) sending said resource handle to said second application to enable said first application and said second application to access said shared device coupled to said serial communication bus and interfaced to said device driver.

2. The method for enabling a plurality of applications to access a shared device coupled to a serial communication bus as described in Claim 1 wherein said serial communication bus is substantially compliant with a version of the Institute of Electrical and Electronics Engineers (IEEE) 1394 bus.

3. The method for enabling a plurality of applications to access a shared device coupled to a serial communication bus as described in Claim 1 wherein said serial communication bus is coupled to said intelligent device..

4. The method for enabling a plurality of applications to access a shared device coupled to a serial communication bus as described in Claim 1 wherein said resource handle comprises a pointer.

5. The method for enabling a plurality of applications to access a shared device coupled to a serial communication bus as described in Claim 1 further comprising the step of f) tracking a number of applications that have allocated said resource for said shared device.

6. The method for enabling a plurality of applications to access a shared device coupled to a serial communication bus as described in Claim 1 further comprising the step of f) storing said resource handle and an identifier of said shared device within a look-up table such that said resource handle corresponds to said identifier of said shared device.

7. The method for enabling a plurality of applications to access a shared device coupled to a serial communication bus as described in Claim 1 further comprising the step of f) in response to a bus reset occurring over said serial communication bus, reallocating said resource to said first application and said second application.

8. A computer readable medium having computer readable code embodied therein for causing a computer to implement the method of any of the preceding claims, wherein the intelligent device is a computer.

9. A computer system comprising: a processor; an addressable data bus coupled to said processor; a serial communication bus; and a computer readable memory coupled to communicate with said processor for performing the steps of the method of any one of claims 1 to 7, wherein said plurality of applications comprises a first application and a second application, and wherein said intelligent device is a computer system.

10. An apparatus for enabling a plurality of applications to access a shared device coupled to a serial communication bus means comprising: a) a first application for requesting allocation of a resource of an intelligent device for said shared device; b) means for allocating said resource for use by a device driver interfaced to said shared device; c) means for sending a resource handle to said first application indicating said resource is allocated to said first application; d) a second application for requesting allocation of a resource for said shared device; and e) means for sending said resource handle to said second application to enable said first application and said second application to access said shared device coupled to said serial communication bus means and interfaced to said device driver.

1 1. The apparatus as described in Claim 10 wherein said serial communication bus means is substantially compliant with a version of the Institute of Electrical and Electronics Engineers (IEEE) 1394 bus.

12. The apparatus as described in Claim 10 wherein said serial communication bus means is coupled to said intelligent device.

13. The apparatus as described in Claim 10 further comprising means for tracking a number of applications that have allocated said resource for said shared device.

14. The apparatus as described in Claim 10 further comprising means for storing said resource handle and an identifier of said shared device within a look-up table such that said resource handle corresponds to said identifier of said shared device.