EP1642245A1 - Speicherverwaltung bei einem tragbaren datenträger - Google Patents

Speicherverwaltung bei einem tragbaren datenträger

Info

Publication number
EP1642245A1
EP1642245A1 EP04740272A EP04740272A EP1642245A1 EP 1642245 A1 EP1642245 A1 EP 1642245A1 EP 04740272 A EP04740272 A EP 04740272A EP 04740272 A EP04740272 A EP 04740272A EP 1642245 A1 EP1642245 A1 EP 1642245A1
Authority
EP
European Patent Office
Prior art keywords
memory
file system
program
management unit
entry
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP04740272A
Other languages
English (en)
French (fr)
Inventor
Erich Englbrecht
Robert Hockauf
Thorsten Ulbricht
Rudolf Schubert
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke+Devrient GmbH
Original Assignee
Giesecke+Devrient GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke+Devrient GmbH filed Critical Giesecke+Devrient GmbH
Publication of EP1642245A1 publication Critical patent/EP1642245A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data

Definitions

  • the invention relates generally to the field of memory management for a portable data carrier and, more particularly, to the field of executing programs contained in a memory of the portable data carrier.
  • a portable data carrier in the sense of the present document can in particular be a chip card (smart card) in different designs or a chip module.
  • the data carriers considered here are relatively powerful and in particular have a memory management unit (MMU).
  • MMU memory management unit
  • Multi-application card Controllers go 32-bit" by Bernd Meier in the magazine SECURE - The Silicon Trust Report, published by Infineon Technologies AG, No. 5, 2002, pages 32 - 35, available at http: // www .silicon-trust.com / pdf / secure_5 / 32_techno_l.pdf, describes a virtual storage management system for portable data carriers.
  • the memory available on the data carrier like a virtual address space, is divided into 64-byte pages.
  • a memory management unit assigns pages in a virtual address space to the respective page frames in physical memory. Programs can still be loaded into the data carrier after it has been personalized. However, a file system for storing such programs and other files is not described.
  • the object of the invention is to provide a technology for memory management in portable data carriers which enables programs stored in a file system to be executed directly at their storage location in the file system ("execute in place").
  • the invention should preferably be able to be used in connection with the most varied of file systems, with no or at most a slight adjustment of the proposed file system being required. Then e.g. particularly reliable and / or particularly space-saving file systems can be used.
  • said object is achieved in whole or in part by a method according to claim 1, a portable data carrier according to claim 10 and a computer program product according to claim 12.
  • the dependent claims relate to preferred embodiments of the invention.
  • the invention is based on the basic idea of storing programs entered in the file system in memory blocks whose position in the memory is compatible with the page frames of the memory specified by the memory management unit.
  • a program entered in the file system can therefore be executed directly in the memory blocks in which the program is stored without copying or moving operations.
  • the entry of such a program contains at least references the memory blocks in which the program is located; in some configurations, the entry may contain all or some of the memory blocks instead of or in addition to the references.
  • the invention thus enables an "execute in place" of the programs entered in the file system, without necessarily requiring that all data structures of the file system are completely aligned or rastered to the limits of the memory frame specified by the memory management unit.
  • a complete rasterization of the file system would have the disadvantage of considerable memory waste, especially with small file sizes and / or large page frames.
  • the invention generally also includes such embodiments; However, configurations are preferred in which at least some data structures of the file system are indicated in the memory of the data carrier independently of the page frame boundaries. are arranged. This applies in particular to data structures that are not part of executable programs, e.g. Directories or regular, non-executable files. In this way, particularly good storage space utilization can be achieved.
  • the file system be able to hold entries for programs, each entry itself containing at least references to memory blocks.
  • the entries can be regular files in which the references are contained. In other configurations, however, the entries correspond to internal management information of the file system.
  • the invention can be integrated into virtually any known file system with little or no change.
  • file systems that avoid memory wastage because they work with data structures of different sizes (e.g. so-called extents).
  • file systems that work purely block-oriented can also be used.
  • a tried and tested and known file system is preferably used.
  • the position of the memory blocks in which the programs are located in the memory in the memory should be compatible with the page frames of the memory specified by the memory management unit.
  • a "page frame” is to be understood according to the customary usage of an area of the real memory, the limits of which are specified by the memory management unit and which is assigned to an adjustable range of virtual addresses by the memory management unit.
  • the memory blocks are considered to be compatible with the page frames specified by the memory management unit if the limits of each memory block fall on page frame limits.
  • each memory block can completely contain multiple page frames.
  • configurations in which the memory blocks and the side frames coincide, that is to say have the same size and the same orientation in the memory, are particularly preferred.
  • Embodiments in which each page frame contains several memory blocks are also not excluded. However, it must be ensured that executable programs are always stored in groups of successive memory blocks, because otherwise the program code in the memory would not be compatible with the arrangement of the page frames.
  • the memory blocks in which the programs entered in the file system are stored can be contained in different configurations in the file system and / or in a separate grid area. It can also be provided that the entire file system is divided into memory blocks that are compatible with the page frames. Administrative information of the file system or non-executable files need not be aligned with the block boundaries, so that the waste can be kept to a minimum.
  • a virtual address space is preferably set up for executing a stored program in that the memory management unit is configured appropriately on the basis of the references contained in the file system.
  • the configuration information can be stored in the main memory of the data carrier or in whole or in part in a separate cache area.
  • the data carrier has a UNIX®-like operating system.
  • a Linux® operating system and a file system provided for this purpose are particularly preferably used in a suitably modified form.
  • file systems are e.g. known per se under the names Ext2fs, Ext3fs, ReiserFS, XFS and JFS.
  • the data carrier according to the invention contains a file system and memory blocks with executable programs.
  • the computer program product according to the invention can be a physical medium with stored program instructions, for example a semiconductor memory or a floppy disk or a CD-ROM.
  • the computer program product can also be a non-physical medium, for example a signal transmitted over a computer network.
  • the computer program product can contain an operating system or an operating system module, which is introduced into the portable data carrier in the course of the manufacture, initialization or personalization thereof.
  • the data carrier and / or the computer program product have features which correspond to the features described above and / or to the features mentioned in the dependent method claims.
  • FIG. 1 is a block diagram of a data carrier with a file system and a separate raster area according to an embodiment of the invention
  • Fig. 2 is a flowchart of a method for executing a program in a data carrier according to the invention.
  • FIG. 3 shows a representation of a file system and a block allocation table in an embodiment modified from FIG. 1.
  • the data carrier 10 shown in FIG. 1 has a processor 12, a memory 14 and an interface circuit 16 for contactless or contact-based communication with an external terminal (not shown) on a single semiconductor chip.
  • the memory 14 is divided into several memory fields.
  • a working memory 18 configured as RAM
  • a read-only memory 20 configured as ROM
  • a non-volatile memory 22 configured as EEPROM are provided as memory fields.
  • program code which implements an operating system 24.
  • the operating system 24 is a variant of the operating system known under the Linu brand, tailored to use in the data carrier 10.
  • the processor 12 includes a processor core 26 and a memory management unit (MMU) 28.
  • the processor core 26 can access the memory 14 via an internal address bus 30, an external address bus 32 and a data bus 34.
  • the memory management unit 28 is connected between the internal and the external address bus 30, 32 in order to convert logical addresses which the processor core 26 outputs to the internal address bus 30 during the execution of the program into physical addresses of the memory 14.
  • the address is implemented with a granularity specified in terms of hardware.
  • the memory management unit 28 assigns a real page in the memory 14 to each page of the virtual address space, if such a real page is available.
  • the real pages in the memory 14 are arranged in a grid specified by the memory management unit 28. Every field in this grid, that is to say every memory area that can accommodate a memory page, is referred to as a page frame.
  • the size of each page frame can be 1 KByte, for example.
  • the mapping of virtual memory pages into the page frames of the memory 14 is determined by page allocation data 36, which are assigned to the memory management unit 28 in the conceptual representation of FIG. 1.
  • the page assignment data 36 can have one page table or a plurality of hierarchically structured page tables. Furthermore, a cache can be provided in order to accelerate access to frequently required parts of the page assignment data 36.
  • the page assignment data 36 can be contained in whole or in part in the memory 14 or in whole or in part in a special cache area of the processor 12.
  • the non-volatile memory 22 contains a file system 38 that has a plurality of entries. 1, a directory 40 and three files 42, 44, 46 are shown as entries in the file system 38.
  • the file system 38 has a structure which is known per se; For example, one of the systems known under the names Ext2f s, Ext3f s, ReiserFS, XFS and JFS can be used as file system 38.
  • the file system 36 can be block oriented and e.g. use a block raster that corresponds to the rasterization of the page frames specified by the memory management unit 28. In other configurations, the file system 38 uses the available memory area, however, regardless of the page frame division.
  • a raster region 48 is further provided in the non-volatile memory 22, which in the exemplary embodiment shown in FIG. 1 is not part of the File system is 38.
  • the grid area 48 is structured such that the grid fields are compatible with the page frames defined by the memory management unit 28.
  • each field shown in the grid area 48 corresponds exactly to one side frame; some of these side frames are provided by way of example with the reference numerals 50.1, 50.2, 50.3, 50.4 - hereinafter referred to collectively as 50.x.
  • the memory 14 contains two programs, which are subdivided into memory blocks and stored in the raster area 48.
  • the memory blocks of the first program are shown in FIG. 1 by vertical hatching, and the memory blocks of the second program are shown by horizontal hatching.
  • a memory block of the first program namely that located in the page frame 50.2, is provided with the reference symbol 52.1 by way of example.
  • the memory block of the second program located in the page frame 50.4 has the reference symbol 52.2.
  • the memory blocks 52.1 and 52.2 and further memory blocks which contain parts of executable programs are referred to in the following as 52.x.
  • the grid area 48 has a block assignment table 54 in the side frame 50.1, which - e.g. in the form of a bit field - indicates which page frames 50.x are occupied by memory blocks 52.x and which page frames 50.x are free.
  • the free side frames 50.x are shown in Fig. 1 without hatching.
  • the block allocation table 54 does not necessarily have to be aligned with the page frame grid; In alternative embodiments, it is provided to store the block allocation table 54 outside of the raster area 48.
  • the link between an entry of an executable program in the file system 38 and the associated memory blocks 52.x is made via References contained in the entry. 1, the entry relating to the first program is formed by the file 42, which in turn contains references - for example pointers or address information - to the memory blocks 52.x of the first program.
  • the reference 56.1 created in the file 42 points to the memory block 52.1 of the first program in the page frame 50.2, and the reference 56.2 contained in the file 46 points to the memory block 52.2 of the second program in the page frame 50.4.
  • the references to memory blocks 52.x created in the file system 38 are referred to below as 56.x.
  • the references 56.x are in regular files of the file system 38 - here e.g. files 42 and 46 - saved.
  • the management structures of the file system 38 there is therefore no difference between these files 42 and 46 and the file 44, which is not related to an executable program.
  • This configuration has the advantage that no special features of the file system 38 have to be taken into account.
  • the entries in the file system 38 which relate to executable programs are not created as regular files, but rather these entries, e.g. to integrate in file system management information.
  • the size and orientation of the memory blocks 52.x in the grid area 48 corresponded exactly to the page frames 50.x specified by the memory management unit 28. In alternative embodiments, however, it can be provided that a memory block 52.x completely fills several page frames 50.x. It can also be provided that several memory blocks 52.x in one Side frame 50.x fall; In this case, however, the administration of the raster area 48 must ensure that such memory blocks 52.x located in a single page frame 50.x always contain a single, contiguous section of the respective program.
  • FIG. 2 shows an exemplary sequence that is carried out by the data carrier 10 in order to start a program contained in the raster area 48.
  • the process begins in step 60 with the operating system 24 receiving a command to execute the program.
  • step 62 the entry relating to the program is opened in the file system 38; in the embodiment of Fig. 1 this entry is a reference file - e.g. as file 42 - designed.
  • the references 56.x contained in the reference file are read in step 64.
  • step 66 page allocation information is generated and transferred to the memory management unit 28. Processing steps are usually required in order to generate the page assignment data 36 from the content of the entry or the reference file in the format required by the memory management unit 28.
  • the page mapping information mentioned in step 66 may correspond to the raw raw data or the page mapping data 36 or intermediate information that is generated during processing.
  • the entry in the file system 38 already contains the required page assignment data 36 in a form that can be used directly by the memory management unit 28.
  • the memory management unit 28 After the reference file - for example the file 42 - has been closed in step 68, the memory management unit 28 provides a virtual address space for the program in step 70. In some configurations Further processing steps of the page allocation data 36 take place, while in other embodiments the memory management unit 28 has already been completely configured in connection with step 66.
  • the memory management unit 28 is now configured such that it maps the logical addresses of the virtual address space of the program to the corresponding memory blocks 52.x in the raster area 48.
  • the program can thus - without a copying or moving process being required - be executed directly at the storage location of the memory blocks 52.x in the raster area 48.
  • the fact that the program in the real address space of the memory 14 is possibly in memory blocks 52.x which are not contiguous and / or are reversed in order is compensated for by the address mapping carried out by the memory management unit 28.
  • a large contiguous address space can be made available.
  • the raster area 48 is separated from the file system 38.
  • 3 shows an alternative embodiment with a block-oriented file system 38 'which takes up the entire available storage space.
  • the entire file system 38 ' is rastered in accordance with the page frames 50.1', 50.2 ', 50.3', 50.4 ', ... - generally designated 50.x' - specified by the memory management unit 28 (FIG. 1). If it is not empty, each page frame 50.x 'in the file system 38' can have either structures of the file system 38 'or a memory block 52.1', 52.2 ', ... - generally designated 52.x' - of an executable program.
  • a file tree with a directory 40 'and three files 42', 44 ', 46' is shown as an example in FIG. 3 as structures of the file system 38 '.
  • Files 42 'and 44' do not refer to executable programs. These files 42 ', 44' are therefore created in accordance with the structure provided by the file system 38 '.
  • non-executable files and other structures of the file system 38 '- for example directories or administrative information - are not oriented towards the borders of the page frames 50.x, but rather are arranged in the memory 14 with as little waste as possible.
  • the file 46 ' represents an entry of an executable program in the file system 38'.
  • the file 46 ' is designed as a reference file, each containing a reference 56.1', 56.2 ', ... - generally designated 56.x '- on the memory blocks 52.x' of the executable program.
  • These memory blocks 52.x 1 occupied with program code are shown hatched in FIG. 1; each memory block 52.x 'fills exactly one page frame 50.x' of the rasterized file system 38 '.
  • the sizes of the page frames 50.x 'and the memory blocks 52.x' may differ from one another, provided that only the position of the memory blocks 52.x 'is compatible with the predetermined limits of the page frames 50.x'.
  • FIG. 3 also shows a block assignment table 54 ', the content of which reflects the exemplary assignment of the section of the rasterized file system 38' shown in FIG. 3.
  • the block allocation table 54 ' can be stored in the file system 38' or separate from it.
  • Various modifications that have already been described above in connection with FIG. 1 can be applied accordingly to the file system 38 'of FIG. 3.
  • it can be advantageous not to create entries in the file system 38 'which correspond to executable programs as regular files - such as the file 46'. Rather, such entries can be integrated into the actual file tree by including the corresponding references 56.x ', for example in administration information of the file system 38'. In some configurations, such administrative information can be so-called index nodes or inodes.
  • a program stored in the rasterized file system 38 'of Fig. 3 is called e.g. according to the method described above and shown in Fig. 2.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • General Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Bei einem Verfahren zur Speicherverwaltung bei einem tragbaren Datenträger (10) werden Programme in ein Dateisystem (38, 38') eingetragen, wobei ein Eintrag eines Programms im Dateisystem (38, 38') zumindest Verweise (56.x, 56.x') auf Speicherblöcke (52.x, 52.x') enthält, in denen sich das Programm in einem Speicher (14) des Datenträgers (10) befindet, und die Speicherblöcke (52.x, 52.x') in ihrer Lage im Speicher (14) mit Seitenrahmen (50.x, 50.x'), die durch eine Speicherverwaltungseinheit (28) vorgegeben sind, verträglich sind, um die Ausführung des Programms an den durch den Eintrag im Dateisystem (38, 38') angegebenen Stellen im Speicher (14) zu ermöglichen. Ein Datenträger (10) und ein Computerprogrammprodukt weisen entsprechende Merkmale auf. Die Erfindung ermöglicht es, in einem Dateisystem (38, 38') eines tragbaren Datenträgers (10) gespeicherte Programme unmittelbar an ihrem Speicherort im Dateisystem (38, 38') auszuführen.

Description

Speicherverwaltung bei einem tragbaren Datenträger
Die Erfindung betrifft allgemein das Gebiet der Speicherverwaltung bei einem tragbaren Datenträger und spezieller das Gebiet der Ausführung von Programmen, die in einem Speicher des tragbaren Datenträgers enthalten sind. Ein tragbarer Datenträger im Sinne des vorliegenden Dokuments kann insbesondere eine Chipkarte (smart card) in unterschiedlichen Bauformen oder ein Chipmodul sein. Die vorliegend betrachteten Datenträger sind relativ leistungsfähig und weisen insbesondere eine Speicherverwaltungseinheit (MMU - memory management unit) auf.
Der Artikel "Multi-application card Controllers go 32-bit" von Bernd Meier in der Zeitschrift SECURE - The Silicon Trust Report, herausgegeben von Infineon Technologies AG, Nr. 5, 2002, Seiten 32 - 35, verfügbar unter http://www.silicon-trust.com/pdf/secure_5/32_techno_l.pdf, beschreibt ein virtuelles Speicherverwaltungssystem für tragbare Datenträger. Der auf dem Datenträger vorhandene Speicher ist, ebenso wie ein virtueller Adreßraum, in Seiten von je 64 Byte Länge gegliedert. Eine Speicherverwaltungseinheit ordnet Seiten in einem virtuellem Adreßraum den jeweiligen Seitenrahmen im physischen Speicher zu. Programme können noch nach der Personalisierung des Datenträgers in diesen nachgeladen werden. Ein Dateisystem zur Speicherung solcher Programme und anderer Dateien ist jedoch nicht beschrieben.
Allgemein besteht bei Dateisystemen für tragbare Datenträger das Bedürfnis, die darin gespeicherten Dateien möglichst speicherplatzsparend - im Idealfall verschnittfrei - anzuordnen. Wenn eine solche nach den Kriterien des Dateisystems im Speicher angeordnete Datei jedoch ein Programm enthält, muß dieses zur Ausführung durch den Datenträger in der Regel kopiert oder verschoben werden. Dies ist erforderlich, weil die Speicherverwaltungseinheit des Datenträgers Seitenrahmen (page frames) im Speicher vorgibt, an deren Grenzen das Programm ausgerichtet sein muß, um ausgeführt werden zu können. Es wäre reiner Zufall, wenn das im Dateisystem befindliche Programm bereits die erforderliche Lage im Speicher aufweisen würde. Der zeit- und speicheraufwendige Kopier- oder Verschiebevorgang stellt einen erheblichen Nachteil dar.
Die Erfindung hat demgemäß die Aufgabe, eine Technik zur Speicherverwaltung bei tragbaren Datenträgern zu schaffen, die es ermöglicht, in einem Dateisystem gespeicherte Programme unmittelbar an ihrem Speicherort im Dateisystem auszuführen ("execute in place"). Vorzugsweise soll die Erfindung im Zusammenhang mit den unterschiedlichsten Dateisystemen einsetzbar sein, wobei keine oder allenfalls eine geringe Anpassung des vorgesehenen Dateisystems erforderlich sein soll. Es können dann z.B. besonders zuverlässige und/ oder besonders speicherplatzsparende Dateisysteme ver- wendet werden.
Erfindungsgemäß wird die genannte Aufgabe ganz oder zum Teil gelöst durch ein Verfahren gemäß Anspruch 1, einen tragbaren Datenträger gemäß Anspruch 10 sowie ein Computerprogrammprodukt gemäß Anspruch 12. Die abhängigen Ansprüche betreffen bevorzugte Ausgestaltungen der Erfindung.
Die Erfindung geht von der Grundüberlegung aus, in dem Dateisystem eingetragene Programme in Speicherblöcken abzulegen, die in ihrer Lage im Speicher mit den durch die Speicherverwaltungseinheit vorgegebenen Seitenrahmen des Speichers verträglich sind. Ein im Dateisystem eingetragenes Programm kann daher ohne Kopier- oder Verschiebevorgänge unmittelbar in den Speicherblöcken, in denen das Programm gespeichert ist, ausgeführt werden. Der Eintrag eines solchen Programms enthält zumindest Verweise auf die Speicherblöcke, in denen sich das Programm befindet; in manchen Ausgestaltungen kann der Eintrag statt der Verweise oder zusätzlich zu den Verweisen auch alle oder einige der Speicherblöcke enthalten.
Die Erfindung ermöglicht somit ein "execute in place" der im Dateisystem eingetragenen Programme, ohne zwingend zu erfordern, daß alle Datenstrukturen des Dateisystems vollständig an den durch die Speicherverwaltungseinheit vorgegebenen Grenzen der Speicherrahmen ausgerichtet bzw. gerastert sind. Eine vollständige Rasterung des Dateisystems hätte insbeson- dere bei kleinen Dateigrößen und/ oder großen Seitenrahmen den Nachteil eines erheblichen Speicher Verschnitts. Zwar umfaßt die Erfindung allgemein auch solche Ausführungsformen; es werden jedoch Ausgestaltungen bevorzugt, bei denen zumindest manche Datenstrukturen des Dateisystems unabhängig von den Seitenrahmengrenzen im Speicher des Datenträgers ange- . ordnet sind. Dies betrifft insbesondere Datenstrukturen, die nicht Bestandteil von ausführbaren Programmen sind, z.B. Verzeichnisse oder reguläre, nicht- ausführbare Dateien. Auf diese Weise läßt sich eine besonders gute Speicherplatzausnutzung erreichen.
Erfindungsgemä-ß wird hinsichtlich des eingesetzten Dateisystems lediglich gefordert, daß das Dateisystem Einträge für Programme aufzunehmen vermag, wobei jeder Eintrag seinerseits zumindest Verweise auf Speicherblöcke enthält. In manchen Ausgestaltungen können die Einträge reguläre Dateien sein, in denen die Verweise enthalten sind. In anderen Ausgestaltungen ent~ sprechen die Einträge dagegen internen Verwaltungsinformationen des Dateisystems.
Die Erfindung kann in so gut wie jedes bekannte Dateisystem mit allenfalls geringem -Änderungsaufwand integriert werden. Hierbei sind insbesondere Dateisysteme zu nennen, die Speicherverschnitt vermeiden, weil sie mit Datenstrukturen unterschiedlicher Größe (z.B. sogenannten Extents) arbeiten. Es können jedoch auch Dateisysteme eingesetzt werden, die rein blockorientiert arbeiten. Vorzugsweise wird ein erprobtes und als zuverlässig bekanntes Dateisystem eingesetzt.
Erfindungsgemäß sollen die Speicherblöcke, in denen sich die Programme im Speicher befinden, in ihrer Lage im Speicher mit den durch die Speicher- verwaltungseinheit vorgegebenen Seitenrahmen (page frames) des Speichers verträglich sein. Hierbei soll unter einem "Seitenrahmen" gemäß dem üblichen Sprachgebrauch ein Bereich des realen Speichers verstanden werden, dessen Grenzen durch die Speicherverwaltungseinheit vorgegeben sind und der durch die Speicherverwaltungseinheit einem einstellbaren Bereich virtueller Adressen zugeordnet wird.
In bevorzugten Ausgestaltungen werden die Speicherblöcke dann als verträglich mit den durch die Speicherverwaltungseinheit vorgegebenen Seitenrahmen angesehen, wenn die Grenzen jedes Speicherblocks auf Seitenrah- mengrenzen fallen. Hierbei kann in manchen Ausführungsformen jeder Speicherblock mehrere Seitenrahmen vollständig enthalten. Besonders bevorzugt sind jedoch Ausgestaltungen, in denen die Speicherblöcke und die Seitenrahmen zusammenfallen, also die gleiche Größe und die gleiche Ausrichtung im Speicher aufweisen. Auch Ausführungsformen, bei denen jeder Seitenrahmen mehrere Speicherblöcke enthält, sind nicht ausgeschlossen. Hierbei muß jedoch darauf geachtet werden, daß ausführbare Programme stets in Gruppen aufeinanderfolgender Speicherblöcke abgelegt werden, weil sonst der im Speicher befindliche Programmcode nicht mit der Anordnung der Seitenrahmen verträglich wäre. Die Speicherblöcke, in denen die im Dateisystem eingetragenen Programme gespeichert sind, können in unterschiedlichen Ausgestaltungen in dem Dateisystem und/ oder in einem gesonderten Rasterbereich enthalten sein. Ferner kann vorgesehen sein, das gesamte Dateisystem in Speicherblöcke zu gliedern, die mit den Seitenrahmen verträglich sind. Verwaltungsinformationen des Dateisystems oder nicht-ausführbare Dateien brauchen hierbei nicht an den Blockgrenzen ausgerichtet zu werden, so daß der Verschnitt gering gehalten werden kann.
Zur Ausführung eines gespeicherten Programms wird vorzugsweise ein virtueller Adreßraum aufgebaut, indem die Speicherverwaltungseinheit auf Grundlage der im Dateisystem enthaltenen Verweise geeignet konfiguriert wird. Die Konfigurationsinformationen können in dem Hauptspeicher des Datenträgers oder ganz oder teilweise in einem separaten Cache-Bereich abgelegt werden.
In vorteilhaften Ausgestaltungen weist der Datenträger ein UNIX®-artiges Betriebssystem auf. Besonders bevorzugt werden ein Linux®-Betriebssystem und ein dafür, vorgesehenes Dateisystem in geeignet modifizierter Form eingesetzt. Solche Dateisysteme sind z.B. unter den Namen Ext2fs, Ext3fs, ReiserFS, XFS und JFS an sich bekannt. Das Buch " linder standing the Linux Kernel" von D. P. Bovet und M. Cesati, O'Reilly Verlag, 2. Auflage, Dezember 2002, auf das hiermit verwiesen wird, enthält eine detaillierte technische Beschreibung des Linux®-Betriebssystems.
Der erfindungsgemäße Datenträger enthält ein Dateisystem und Speicherblöcke mit ausführbaren Programmen. Das erfindungsgemäße Computerprogrammprodukt kann ein körperliches Medium mit gespeicherten Programmbefehlen sein, beispielsweise ein Halbleiterspeicher oder eine Diskette oder eine CD-ROM. Das Computerprogrammprodukt kann jedoch auch ein nicht-körperliches Medium sein, beispielsweise ein über ein Computernetzwerk übermitteltes Signal. Insbesondere kann das Computerprogrammprodukt ein Betriebssystem oder ein Betriebssystemmodul enthalten, das im Zuge der Herstellung oder der Initialisierung oder der Personalisierung eines tragbaren Datenträgers in diesen eingebracht wird.
In bevorzugten Ausgestaltungen weisen der Datenträger und/ oder das Computerprogrammprodukt Merkmale auf, die den oben beschriebenen und/ oder den in den abhängigen Verfahrensansprüchen genannten Merk- malen entsprechen.
Weitere Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden Beschreibung mehrerer Ausführungsbeispiele und Ausführungsalternativen hervor. Es wird auf die Zeichnung verwiesen, in denen zeigen:
Fig. 1 ein Blockdiagramm eines Datenträgers mit einem Dateisystem und einem separaten Rasterbereich nach einem Ausführungsbeispiel der Erfindung,
Fig. 2 ein Flußdiagramm eines Verfahrens zur Ausführung eines Programms bei einem erfindungsgemäßen Datenträger, und
Fig. 3 eine Darstellung eines Dateisystems und einer Blockbelegungstabelle in einer gegenüber Fig. 1 abgewandelten Ausführungsform. Der in Fig. 1 dargestellte Datenträger 10 weist auf einem einzigen Halbleiter- chip einen Prozessor 12, einen Speicher 14 und eine Schnittstellenschaltung 16 zur kontaktlosen oder kontaktgebundenen Kommunikation mit einem externen Terminal (nicht gezeigt) auf.
Der Speicher 14 ist in mehrere Speicherfelder unterteilt. Im vorliegenden Ausführungsbeispiel sind als Speicherfelder ein als RAM ausgestalteter Arbeitsspeicher 18, ein als ROM ausgestalteter Festwertspeicher 20 und ein als EEPROM ausgestalteter, nicht-flüchtiger Speicher 22 vorgesehen. Im Speicher 14 - und zwar teils im Festwertspeicher 20 und teils im nicht-flüchtigen Speicher 22 - befindet sich Programmcode, der ein Betriebssystem 24 implementiert. Das Betriebssystem 24 ist im vorliegenden Ausführungsbeispiel eine auf den Einsatz im Datenträger 10 zugeschnittene Variante des unter der Marke Linu bekannten Betriebssystems.
Der Prozessor 12 beinhaltet einen Prozessorkern 26 und eine Speicherverwaltungseinheit (MMU - memory management unit) 28. Der Prozessorkern 26 vermag über einen internen Adreßbus 30, einen externen Adreßbus 32 und einen Datenbus 34 auf den Speicher 14 zuzugreifen. Die Speicherverwal- tungseinheit 28 ist zwischen den internen und den externen Adreßbus 30, 32 geschaltet, um logische Adressen, die der Prozessorkern 26 bei der Programmausführung auf den internen Adreßbus 30 ausgibt, in physische Adressen des Speichers 14 umzusetzen.
Die Adreßumsetzung erfolgt mit einer hardwaremäßig vorgegebenen Granularität. Die Speicherverwaltungseinheit 28 ordnet je einer Seite des virtuellen Adreßraums je eine reale Seite im Speicher 14 zu, falls eine solche reale Seite verfügbar ist. Die realen Seiten im Speicher 14 sind in einem durch die Speicherverwaltungseinheit 28 vorgegebenen Raster angeordnet. Jedes Feld in diesem Raster, also jeder Speicherbereich, der eine Speicherseite aufzunehmen vermag, wird als Seitenrahmen bezeichnet. Die Größe jedes Seitenrahmens kann z.B. 1 KByte betragen.
Die Abbildung virtueller Speicherseiten in die Seitenrahmen des Speichers 14 wird durch Seitenzuordnungsdaten 36 bestimmt, die in der konzeptuellen Darstellung von Fig. 1 der Speicherverwaltungseinheit 28 zugeordnet sind. Die Seitenzuordnungsdaten 36 können eine Seitentabelle oder mehrere hierarchisch gegliederte Seitentabellen aufweisen. Ferner kann ein Cache vorgesehen sein, um Zugriffe auf häufig benötigte Teile der Seitenzuordnungsdaten 36 zu beschleunigen. In unterschiedlichen Ausgestaltungen können die Seitenzuordnungsdaten 36 ganz oder teilweise im Speicher 14 oder ganz oder teilweise in einem speziellen Cache-Bereich des Prozessors 12 enthalten sein.
Der nicht-flüchtige Speicher 22 enthält ein Dateisystem 38, das eine Vielzahl von Einträgen aufweist. In Fig. 1 sind als Einträge des Dateisystems 38 beispielhaft ein Verzeichnis 40 und drei Dateien 42, 44, 46 gezeigt. Das Dateisystem 38 weist im vorliegenden Ausführungsbeispiel eine an sich bekannte Struktur auf; beispielsweise kann eines der unter den Namen Ext2f s, Ext3f s, ReiserFS, XFS und JFS bekannten Systeme als Dateisystem 38 eingesetzt werden. Das Dateisystem 36 kann blockorientiert sein und z.B. eine Block- rasterung verwenden, die mit der durch die Speicherverwaltungseinheit 28 vorgegebenen Rasterung der Seitenrahmen übereinstimmt. In anderen Aus- gestaltungen nutzt das Dateisystem 38 den zur Verfügung stehenden Speicherbereich dagegen ohne Rücksicht auf die Seitenrahmeneinteilung.
Im nicht-flüchtigen Speicher 22 ist ferner ein Rasterbereich 48 vorgesehen, der in dem in Fig. 1 gezeigten Ausführungsbeispiel nicht Bestandteil des Dateisystems 38 ist. Der Rasterbereich 48 ist so gegliedert, daß die Rasterfelder mit den durch die Speicherverwaltungseinheit 28 definierten Seitenrahmen verträglich sind. In dem Ausführungsbeispiel von Fig. 1 entspricht jedes im Rasterbereich 48 gezeigte Feld genau einem Seitenrahmen; einige dieser Seitenrahmen sind beispielhaft mit den Bezugszeichen 50.1, 50.2, 50.3, 50.4 - im folgenden zusammenfassend mit 50.x bezeichnet - versehen.
Im Beispiel von Fig. 1 enthält der Speicher 14 zwei Programme, die in Speicherblöcke untergliedert und in dem Rasterbereich 48 gespeichert sind. Die Speicherblöcke des ersten Programms sind in Fig. 1 beispielhaft durch eine senkrechte Schraffur gezeigt, und die Speicherblöcke des zweiten Programms sind durch eine waagerechte Schraffur gezeigt. Ein Speicherblock des ersten Programms, nämlich der in dem Seitenrahmen 50.2 befindliche, ist beispielhaft mit dem Bezugszeichen 52.1 versehen. Der in dem Seiterurahmen 50.4 befindliche Speicherblock des zweiten Programms trägt das Bezugszeichen 52.2. Die Speicherblöcke 52.1 und 52.2 sowie weitere Speicherblöcke, die Teile von ausführbaren Programmen enthalten, werden im folgenden zusammenfassend mit 52.x bezeichnet.
Der Rasterbereich 48 weist im Seitenrahmen 50.1 eine Blockbelegungstabelle 54 auf, die - z.B. in Form eines Bitfeldes - angibt, welche Seitenrahmen 50.x durch Speicherblöcke 52.x belegt und welche Seitenrahmen 50.x frei sind. Die freien Seitenrahmen 50.x sind in Fig. 1 ohne Schraffur dargestellt. Die Blockbelegungstabelle 54 braucht nicht notwendigerweise an dem Seitenrah- menraster ausgerichtet zu sein; in Ausführungsalternativen ist vorgesehen, die Blockbelegungstabelle 54 außerhalb des Rasterbereichs 48 zu speichern.
Die Verknüpfung zwischen einem Eintrag eines ausführbaren Programms im Dateisystem 38 und den zugehörigen Speicherblöcken 52.x erfolgt über Verweise, die im Eintrag enthalten sind. So wird beispielsweise in der Darstellung von Fig. 1 der das erste Programm betreffende Eintrag durch die Datei 42 gebildet, die ihrerseits Verweise - z.B. Zeiger oder Adreßinforma- tionen - auf die Speicherblöcke 52.x des ersten Programms enthält. So zeigt z.B. der in der Datei 42 angelegte Verweis 56.1 auf den Speicherblock 52.1 des ersten Programms im Seitenrahmen 50.2, und der in der Datei 46 enthaltene Verweis 56.2 zeigt auf den Speicherblock 52.2 des zweiten Programms im Seite rahmen 50.4. Zusammenfassend werden die im Dateisystem 38 angelegten Verweise auf Speicherblöcke 52.x im folgenden mit 56.x bezeich- net.
In dem hier beschriebenen Ausführungsbeispiel sind die Verweise 56.x in regulären Dateien des Dateisystems 38 - hier z.B. den Dateien 42 und 46 - gespeichert. Im Hinblick auf die Verwaltungsstrukturen des Dateisystems 38 besteht daher kein Unterschied zwischen diesen Dateien 42 und 46 und der Datei 44, die nicht mit einem ausführbaren Programm in Beziehung steht. Diese Ausgestaltung hat den Vorteil, daß keinerlei Besonderheiten des Dateisystems 38 berücksichtigt werden müssen. In Ausführungsalternativen kann jedoch vorgesehen sein, die Einträge im Dateisystem 38, die sich auf ausführ- bare Programme beziehen, nicht als reguläre Dateien anzulegen, sondern diese Einträge z.B. in Verwaltungsinformationen des Dateisystems zu integrieren.
In dem bislang beschriebenen Ausführungsbeispiel stimmten die Speicher- blocke 52.x in ihrer Größe und Ausrichtung im Rasterbereich 48 genau mit den durch die Speicherverwaltungseinheit 28 vorgegebenen Seitenrahmen 50.x überein. In Ausführungsalternativen kann dagegen vorgesehen sein, daß ein Speicherblock 52.x mehrere Seitenrahmen 50.x vollständig ausfüllt. Ebenso kann vorgesehen sein, daß mehrere Speicherblöcke 52.x in einen Seitenrahmen 50.x fallen; hierbei muß jedoch durch die Verwaltung des Rasterbereichs 48 sichergestellt werden, daß solche in einem einzigen Seitenrahmen 50.x befindliche Speicherblöcke 52.x stets einen einzigen, zusammenhängenden Abschnitt des jeweiligen Programms enthalten.
Fig. 2 zeigt einen beispielhaften Ablauf, der von dem Datenträger 10 ausgeführt wird, um ein im Rasterbereich 48 enthaltenes Programm zu starten. Der Ablauf beginnt in Schritt 60 damit, daß das Betriebssystem 24 einen Befehl zur Ausführung des Programms erhält. In Schritt 62 wird der das Programm betreffende Eintrag im Dateisystem 38 geöffnet; in dem Ausführungsbeispiel von Fig. 1 ist dieser Eintrag als Verweisdatei - z.B. als Datei 42 - ausgestaltet. Die in der Verweisdatei enthaltenen Verweise 56.x werden in Schritt 64 gelesen.
In Schritt 66 werden Seitenzuordnungsinformationen erzeugt und an die Speicherverwaltungseinheit 28 übergeben. Hierbei sind in der Regel Verarbeitungsschritte erforderlich, um aus dem Inhalt des Eintrags bzw. der Verweisdatei die Seitenzuordnungsdaten 36 in dem von der Speicherverwaltungseinheit 28 benötigten Format zu generieren. Die in Schritt 66 er- wähnten Seitenzuordnungsinformationen können den unverarbeiteten Rohdaten oder den Seitenzuordnungsdaten 36 oder Zwischeninf ormationen, die bei der Verarbeitung anfallen, entsprechen. In besonders einfachen Ausgestaltungen enthält der Eintrag im Dateisystem 38 bereits die benötigten Seitenzuordnungsdaten 36 in einer von der Speicherverwaltungseinheit 28 unmittelbar verwendbaren Form.
Nach dem Schließen der Verweisdatei - z.B. der Datei 42 - in Schritt 68 stellt die Speicherverwaltungseinheit 28 in Schritt 70 einen virtuellen Adreßraum für das Programm zur Verfügung. Hierbei können in manchen Ausgestal- tungen weitere Verarbeitungsschritte der Seitenzuordnungsdaten 36 erfolgen, während in anderen Ausführungsformen die Speicherverwaltungs- einheit 28 schon im Zusammenhang mit Schritt 66 vollständig konfiguriert wurde.
Die Speicherverwaltungseinheit 28 ist nun so konfiguriert, daß sie die logischen Adressen des virtuellen Adreßraums des Programms auf die entsprechenden Speicherblöcke 52.x im Rasterbereich 48 abbildet. Das Programm kann damit - ohne daß ein Kopier- oder Verschiebevorgang erforderlich wäre - unmittelbar an dem Speicherort der Speicherblöcke 52.x im Rasterbereich 48 ausgeführt werden. Die Tatsache, daß das Programm im realen Adreßraum des Speichers 14 möglicherweise in Speicherblöcken 52.x vorliegt, die nicht zusammenhängen und/ oder in ihrer Reihenfolge vertauscht sind, wird durch die von der Speicherverwalrungseinheit 28 vorgenommene Adreßabbildung ausgeglichen. Für das Programm kann somit, falls gewünscht, z.B. ein großer zusammenhängender Adreßraum zur Verfügung gestellt werden.
Bei dem Ausführungsbeispiel von Fig. 1 ist der Rasterbereich 48 von dem Dateisystem 38 getrennt. Fig. 3 zeigt eine Ausführungsalternative mit einem blockorientierten Dateisystem 38', das den gesamten zur Verfügung stehenden Speicherplatz einnimmt. Das gesamte Dateisystem 38' ist gemäß den durch die Speicherverwaltungseinheit 28 (Fig. 1) vorgegebenen Seitenrahmen 50.1', 50.2', 50.3', 50.4', ... - allgemein mit 50.x' bezeichnet - gerastert. Jeder Seitenrahmen 50.x' im Dateisystem 38' kann, sofern er nicht leer ist, entweder Strukturen des Dateisystems 38' oder einen Speicherblock 52.1', 52.2', ... - allgemein mit 52.x' bezeichnet - eines ausführbaren Programms aufweisen. Als Strukturen des Dateisystems 38' sind in Fig. 3 beispielhaft ein Dateibaum mit einem Verzeichnis 40' und drei Dateien 42', 44', 46' dargestellt. Die Dateien 42' und 44' beziehen sich nicht auf ausführbare Programme. Diese Dateien 42', 44' Werden daher gemäß der durch das Dateisystem 38' vorge- sehenen Struktur angelegt. Insbesondere ist in manchen Ausgestaltungen vorgesehen, nicht-ausführbare Dateien und andere Strukturen des Dateisystems 38' - z.B. Verzeichnisse oder Verwaltungsinformationen - nicht an den Grenzen der Seitenrahmen 50.x zu orientieren, sondern sie möglichst verschnittfrei im Speicher 14 anzuordnen. Dies ist in Fig. 3 am Beispiel der Datei 42' veranschaulicht, die sich über einen zusammenhängenden Speicherbereich, welcher je einen Teil der Seitenrahmen 50.1' und 50.2' einnimmt, erstreckt.
Die Datei 46' stellt einen Eintrag eines ausführbaren Programms im Datei- system 38' dar. Wie bereits im Zusammenhang mit Fig. 1 erläutert, ist die Datei 46' als Verweisdatei ausgestaltet, die je einen Verweis 56.1', 56.2', ... - allgemein mit 56.x' bezeichnet - auf die Speicherblöcke 52.x' des ausführbaren Programms aufweist. Diese mit Programmcode belegten Speicherblöcke 52.x1 sind in Fig. 1 schraffiert gezeigt; jeder Speicherblock 52.x' füllt exakt einen Seitenrahmen 50.x' des gerasterten Dateisystems 38' aus. In Ausführungsalternativen können, wie oben bereits erwähnt, die Größen der Seitenrahmen 50.x' und der Speicherblöcke 52.x' voneinander abweichen, sofern nur die Lage der Speicherblöcke 52.x' mit den vorgegebenen Grenzen der Seitenrahmen 50.x' verträglich ist.
Fig. 3 zeigt ferner eine Blockbelegungstabelle 54', deren Inhalt die beispielhafte Belegung des in Fig. 3 dargestellten Abschnitts des gerasterten Dateisystems 38' widerspiegelt. Die Blockbelegungstabelle 54' kann in dem Dateisystem 38' gespeichert oder von diesem getrennt sein. Diverse Abwandlungen, die oben bereits im Zusammenhang mit Fig. 1 beschrieben worden sind, lassen sich entsprechend auf das Dateisystem 38' von Fig. 3 anwenden. Insbesondere kann es vorteilhaft sein, Einträge im Datei- system 38', die ausführbaren Programmen entsprechen, nicht als reguläre Dateien - wie z.B. die Datei 46' - anzulegen. Vielmehr können solche Einträge in den eigentlichen Dateibaum integriert werden, indem die entsprechenden Verweise 56.x' z.B. in Verwaltungsinformationen des Dateisystems 38' aufgenommen werden. Solche Verwaltungsinformationen können in man- chen Ausgestaltungen sogenannte index nodes oder inodes sein.
Der Aufruf eines in dem gerasterten Dateisystem 38' von Fig. 3 gespeicherten Programms erfolgt z.B. gemäß dem oben beschriebenen und in Fig. 2 dargestellten Verfahren.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zur Speicherverwaltung bei einem tragbaren Datenträger (10), der mindestens einen Speicher (14) sowie einen Prozessor (12) mit einer Speicherverwaltungseinheit (28) aufweist, wobei der Prozessor (12) zur Ausführung von Programmen, die in dem Speicher (14) enthalten sind, unter Verwendung der Speicherverwaltungseinheit (28) auf den Speicher (14) zuzugreifen vermag, dadurch gekennzeichnet, daß in dem Speicher (14) ferner ein Dateisystem (38, 38') verwaltet wird, in dem zumindest einige der Programme eingetragen sind, wobei ein Eintrag eines Programms im Dateisystem (38, 38') zumindest Verweise (56.x, 56.x') auf Speicherblöcke (52.x, 52.x1) enthält, in denen sich das Programm im Speicher- (14) befindet, und die Speicherblöcke (52.x, 52.x') in ihrer Lage im Speicher (14) mit den durch die Speicherverwaltungseinheit (28) vorgegebenen Seitenrahmen (50.x, 50.x') des Speichers (14) verträglich sind, um dem Prozessor (12) die Ausführung des Programms an den durch den Eintrag im Dateisystem (38, 38') angegebenen Stellen im Speicher (14) zu ermöglichen.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß jeder Speicherblock (52.x, 52.x'), auf den ein Eintrag eines Programms im Dateisystem (38, 38') verweist, an seinen Grenzen mit Grenzen von Seitenrahmen (50.x, 50.x') im Speicher (14), die durch die Speicherverwaltungseinheit (28) vorgegeben sind, übereinstimmt.
3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, daß die Speicherblöcke (52.x), in denen die im Dateisystem (38) eingetragenen Programme gespeichert sind, in einem von dem Dateisystem (38) getrennten Rasterbereich (48) enthalten sind.
4. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekenn- zeichnet, daß das Dateisystem (38') die Speicherblöcke (52.x1), in denen die im Dateisystem (38') eingetragenen Programme gespeichert sind, enthält.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekenn- zeichnet, daß das Dateisystem (38, 38') mindestens eine Datenstruktur, insbesondere ein Verzeichnis (40, 40') oder eine Datei (42, 44, 46, 42', 44', 46'), aufweist, deren Lage im Speicher (14) unabhängig von den durch die Speicherverwaltungseinheit (28) vorgegebenen Seitenrahmen (50.x, 50.x1) ist.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß jeder Eintrag eines Programms im Dateisystem (38, 38') eine reguläre Datei (42, 6, 6') ist.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß Informationen über freie und belegte Seitenrahmen (50.x, 50.x') in einer Blockbelegungstabelle (54, 54') gespeichert werden.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß zur Ausführung eines Programms der entsprechende Eintrag im Dateisystem (38, 38') ausgewertet wird, und daß auf Grundlage der in dem Eintrag enthaltenen Verweise (56.x, 56.x') die Speicherverwaltungseinheit (28) derart zum Aufbau eines virtuellen Adreßraums konfiguriert wird, daß das Programm an den durch den Eintrag angegebenen Stellen im Speicher (14) ausgeführt wird.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, daß der Datenträger (10) ein UNIX-artiges Betriebssystem (24), insbesondere ein Linux-Betriebssystem, aufweist.
10. Tragbarer Datenträger (10), insbesondere Chipkarte oder Chip- modul, der mindestens einen Speicher (14) sowie einen Prozessor (12) mit einer Speicherverwaltungseinheit (28) aufweist, wobei der Prozessor (12) zur Ausführung von Programmen, die in dem Speicher (14) enthalten sind, unter Verwendung der Speicherverwaltungseinheit (28) auf den Speicher (14) zuzugreifen vermag, dadurch gekennzeichnet, daß der Speicher (14) ferner ein Dateisystem (38, 38') aufweist, in dem zumindest einige der Programme eingetragen sind, wobei ein Eintrag eines Programms im Dateisystem (38, 38') zumindest Verweise (56.x, 56.x') auf Speicherblöcke (52.x, 52.x') enthält, in denen sich das Programm im Spei- eher (14) befindet, und die Speicherblöcke (52.x, 52.x') in ihrer Lage im Speicher (14) mit den durch die Speicherverwaltungseinheit (28) vorgegebenen Seitenrahmen (50.x, 50.x') des Speichers (14) verträglich sind, um dem Prozessor (12) die Ausführung des Programms an den durch den Eintrag im Dateisystem (38, 38') ange- gebenen Stellen im Speicher (14) zu ermöglichen.
11. Tragbarer Datenträger (10) nach Anspruch 10, dadurch gekennzeichnet, daß der Speicher (14) ferner Programmbefehle enthält, die den Prozessor (12) zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 9 veranlassen.
12. Computerprogrammprodukt, das maschinenlesbare Programm- befehle für einen Prozessor (12) eines tragbaren Datenträgers (10) aufweist, die den Prozessor (12) zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 9 veranlassen.
EP04740272A 2003-06-27 2004-06-24 Speicherverwaltung bei einem tragbaren datenträger Withdrawn EP1642245A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE2003129145 DE10329145A1 (de) 2003-06-27 2003-06-27 Speicherverwaltung bei einem tragbaren Datenträger
PCT/EP2004/006859 WO2005001780A1 (de) 2003-06-27 2004-06-24 Speicherverwaltung bei einem tragbaren datenträger

Publications (1)

Publication Number Publication Date
EP1642245A1 true EP1642245A1 (de) 2006-04-05

Family

ID=33546696

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04740272A Withdrawn EP1642245A1 (de) 2003-06-27 2004-06-24 Speicherverwaltung bei einem tragbaren datenträger

Country Status (3)

Country Link
EP (1) EP1642245A1 (de)
DE (1) DE10329145A1 (de)
WO (1) WO2005001780A1 (de)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5754817A (en) * 1994-09-29 1998-05-19 Intel Corporation Execution in place of a file stored non-contiguously in a non-volatile memory
DE19723676A1 (de) * 1997-06-05 1998-08-27 Siemens Ag Verfahren zum Nachladen von Programmen auf eine Chip-Karte
US6574747B2 (en) * 2000-06-02 2003-06-03 Microsoft Corporation Extensible execute in place (XIP) architecture and related methods

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BERND MEIER: "Multi-Application Card Controllers Go 32-Bit", SECURE, vol. 5, 1 January 2002 (2002-01-01) - 1 January 2002 (2002-01-01), Munich, pages 32 - 35 *
See also references of WO2005001780A1 *

Also Published As

Publication number Publication date
DE10329145A1 (de) 2005-02-10
WO2005001780A1 (de) 2005-01-06

Similar Documents

Publication Publication Date Title
DE3780807T2 (de) Verfahren zum schnellen oeffnen von mit pfadnamen identifizierten plattendateien.
DE69526751T2 (de) Multiprozessorsystem zur lokalen Verwaltung von Adressenübersetzungstabellen
DE4218025C2 (de) Vorrichtung und Verfahren zur automatischen Zuordnung von Datenspeichereinrichtungen in einem Computersystem
DE3151745C2 (de)
DE3807997A1 (de) Ic-karte mit interner fehlerpruefung
DE3280414T2 (de) Methode fuer den betrieb eines virtuellen speicherorganisationssystems.
DE1499182A1 (de) Elektrische Datenverarbeitungsanlage
DE68929080T2 (de) Anordnung zum Speichern von Informationen für einen Datenanbieterprozessor
DE69123493T2 (de) Verarbeitungsverfahren und Gerät um einen Dateinamen von einem logischen zu einem richtigen Namen zu erstellen
DE2926322A1 (de) Speicher-subsystem
DE19645128A1 (de) Verfahren zum Verwalten von Dokumenten
EP1352318B1 (de) Mikroprozessorschaltung für tragbare datenträger
DE68925376T2 (de) In Direktabbildung und in Bankabbildung wirksamer Informationsprozessor und Verfahren zum Schalten der Abbildungsschemas
DE10120615B4 (de) Dynamische Speicherverwaltung für Objekte unterschiedlicher Größe
DE19538448B4 (de) Datenbankmanagementsystem sowie Datenübertragungsverfahren
DE10059145B4 (de) Fahrzeuginformationsprozessor zum Bereitstellen von Karteninformation auf Grundlage von Kartendaten
DE10209803A1 (de) Verfahren und Vorrichtung zum Liefern eines Dateisystemzugriffs auf ein Plattenarray
WO2005001780A1 (de) Speicherverwaltung bei einem tragbaren datenträger
DE112023003040T5 (de) Elektronische Steuervorrichtung, Fahrzeugsteuersystem und Aufgabensteuerverfahren
EP1673743B1 (de) Zugreifen auf datenelemente in einem tragbaren datenträger
DE10343328A1 (de) Verfahren zum Abbilden eines hierarchischen technischen Systems in eine relationale Datenbank
EP3186711B1 (de) Speicherverwaltung für einen token
DE102004006308B4 (de) Verfahren zum Verändern von Programmcode eines tragbaren Datenträgers mittels Patchdaten
DE2816838C2 (de) Verfahren und Prioritätssteuereinheit zum Zuordnen von Prioritäten
EP1429254B1 (de) Interrupt-Behandlung in einem CAN-Knoten

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060127

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
RIN1 Information on inventor provided before grant (corrected)

Inventor name: ULBRICHT, THORSTEN

Inventor name: HOCKAUF, ROBERT

Inventor name: SCHUBERT, RUDOLF

Inventor name: ENGLBRECHT, ERICH

17Q First examination report despatched

Effective date: 20101229

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170727