Browse Prior Art Database

Simulating data/operating environment for an application using dynamically loadable wrappers Disclosure Number: IPCOM000240057D
Publication Date: 2014-Dec-29
Document File: 3 page(s) / 37K

Publishing Venue

The Prior Art Database


With the existence of so many technologies, testing on all possible combinations can be challenging from procuring hardware, setting up environment etc. This article presents one of the ways to simulate the required environment by users themselves.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 3

Simulating data/operating environment for an application using dynamically loadable wrappers

Disclosed is a framework which can be used to simulate an unsupported environment by underlying Operating System. With the variety of technologies emerging to address the growing need of computing power, applications are also expected to adapt themselves to these technologies. Besides applications being adaptable, they need to be scalable. In rapid testing scenarios, it can be challenging to get the operating environment in place for testing applications for such features. Challenge could be in terms of cost in acquiring high end resources, the number of resources acquired and possibly time taken to setup the resources.

For example: Testing of 64-bit inode numbers support in an application is a challenge. Team needs to have TB sized disk, then spend time to create files on it. The number of files to be created should cross 32-bit boundary for testing if, application handles 64-bit inode numbers correctly.

Known solution: Use simulators, but above scenarios can not be simulated with existing simulators. FUSE hack in ext4 filesystem, where initial inode is bumped up but this is filesystem specific.

Idea is to load library wrapper and kernel extensions as needed during the load of the application. These wrappers work in the scope of the application only.

1. Wrappers can be tuned to do simulate anything required. Inject errors, modify the format of the data or anything.

2. Help remove dependency on resources for testing the application in multiple environments.

3. These wrappers will help ensure the independence from underlying layer. In our example: it will file system independent solution.

4. Scalability comes attached with it as the wrappers can altered to return whatever required. In our example the solution becomes bit-ness independent tomorrow if, file system moves to 128bit we can scale such solutions easily.

Existing framework:


Page 02 of 3

As we see, in existing framework libraries and system calls come as a part of the operating system and are fixed. Users have no option to modify...