프로그래밍 언어 포럼 순위 (랭킹)

http://www.tiobe.com/tiobe_index/index.htm

TIOBE Programming Community Index for September 2009

September Headline: PHP enters top 3 for the first time

The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, MSN, Yahoo!, Wikipedia and YouTube are used to calculate the ratings. Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.

The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system. The definition of the TIOBE index can be found here.

Position
Sep 2009		Position
Sep 2008		Delta in PositionProgramming LanguageRatings
Sep 2009		Delta
Sep 2008		Status
11Java19.383%-1.33%A
22C16.861%+1.48%A
35 PHP10.156%+0.91%A
43 C++9.988%-0.73%A
54 (Visual) Basic9.196%-1.29%A
67 Perl4.528%-0.31%A
78 C#4.186%-0.15%A
86 Python3.930%-1.08%A
99JavaScript2.995%-0.14%A
1011 Ruby2.377%-0.38%A
1110 Delphi1.972%-1.08%A
1218 Pascal0.961%+0.56%A
1316 Lisp/Scheme0.842%+0.42%A--
1413 PL/SQL0.819%+0.12%A
1514 SAS0.781%+0.14%A
1624 ABAP0.705%+0.42%A
1712 D0.588%-0.68%B
1842 Objective-C0.585%+0.48%B
1917 Lua0.507%+0.09%B
2025 MATLAB0.506%+0.25%B


Long term trends

The long term trends for the top 10 programming languages can be found in the line diagram below.

Other programming languages

The complete top 50 of programming languages is listed below. This overview is published unofficially, because it could be the case that we missed a language. If you have the impression there is a programming language lacking, please notify us at tpci@tiobe.com.

PositionProgramming LanguageRatings
21RPG (OS/400)0.457%
22ActionScript0.438%
23COBOL0.421%
24Ada0.389%
25Scratch0.383%
26Fortran0.373%
27Transact-SQL0.367%
28Logo0.365%
29FoxPro/xBase0.321%
30S-lang0.281%
31PowerShell0.263%
32Scala0.238%
33Erlang0.231%
34Prolog0.230%
35NXT-G0.229%
36ML0.228%
37Haskell0.211%
38Tcl/Tk0.210%
39Smalltalk0.175%
40Bourne shell0.162%
41Alice0.161%
42Caml/F#0.161%
43Focus0.159%
44LabVIEW0.159%
45Forth0.157%
46Groovy0.154%
47PL/I0.136%
48Awk0.136%
49J0.136%
50ABC0.123%

The Next 50 Programming Languages

The following list of languages denotes #51 to #100. Since the differences are relatively small, the programming languages are only listed (in alphabetical order).

  • AD, Algol, Alpha, APL, Applescript, Beta, Boo, C shell, cg, CL (OS/400), Clean, Clojure, cT, Curl, Dylan, Eiffel, Euphoria, Factor, Falcon, Fan, Icon, IDL, Inform, Io, JavaFX Script, Lingo, MAD, Magic, Maple, Mathematica, MAX/MSP, Modula-2, Modula-3, MUMPS, Natural, Oberon, Occam, Oz, Postscript, Progress, Q, R, Revolution, REXX, SIGNAL, SPSS, SuperCollider, VBScript, VHDL, XSLT


September Newsflash - Brought to you by Paul Jansen

  • This month the following changes have been made to the definition of the index:
    • CPython and JPython have been added to the Python grouping thanks to Dan Stromberg
    • Dave Leffingwell pointed out that it is also possible to program in an object-oriented way in MATLAB. So MATLAB is now 50% object-oriented in our overviews
  • To see the bigger picture, please find the positions of the top 10 programming languages from 4, 10 and 25 years ago in the table below.

    Programming LanguagePosition
    Sep 2009    		Position
    Sep 2005    		Position
    Sep 1999    		Position
    Sep 1984
    Java114-
    C2211
    PHP35--
    C++43211
    (Visual) Basic5634
    Perl6411-
    C#7722-
    Python8826-
    JavaScript9921-
    Ruby1025--


  • The previous winners of the "Language of the Year" award are shown below.

    YearWinner
    2008 C
    2007 Python
    2006 Ruby
    2005 Java
    2004 PHP
    2003 C++

  • In the tables below some long term trends are listed about categories of languages. The object-oriented paradigm lost 1.5% to procedural and functional languages in one month's time. The popularity of dynamically typed languages seems to stabilize (see trend diagram below).

    CategoryRatings Sep 2009Delta Sep 2008
    Object-Oriented Languages 52.8% -4.3%
    Procedural Languages 43.1% +3.3%
    Functional Languages 2.9% +0.7%
    Logical Languages 1.2% +0.3%


    CategoryRatings Sep 2009Delta Sep 2008
    Statically Typed Languages 58.3% -0.4%
    Dynamically Typed Languages 41.7% +0.4%


Frequently Asked Questions

  • Q: What definition of programming languages has been used?

    A: A language is considered a programming language if it is Turing complete. As a consequence, HTML and XML are not considered programming languages. This also holds for data query language SQL. SQL is not a programming language because it is, for instance, impossible to write an infinite loop in it. On the other hand, SQL extensions PL/SQL and Transact-SQL are programming languages. ASP and ASP.NET are also not programming languages because they make use of other languages such as JavaScript and VBScript or .NET compatible languages. The same is true for frameworks such as Ruby on Rails, ColdFusion, Cocoa, and technologies such as AJAX. Finally, we have also excluded assembly languages, although Turing complete, because they have a very different nature.

  • Q: How are dialects of languages grouped?

    A: Some languages are grouped together because they are very similar to each other. An example is the language entry Basic which covers Visual Basic, QBasic, Microsoft Basic, etc. VB.NET has been added as well to the Visual Basic entry because it is often referred to as Visual Basic. The ratings for a collection of languages is calculated by taking the maximum of all individual entries (not its sum!).

  • Q: Am I allowed to show the TIOBE index in my weblog/presentation/publication?

    A: This is OK provided that you refer to its original source: www.tiobe.com.

  • Q: I would like to have the complete data set of the TIOBE index. Is this possible?

    A: We spent a lot of effort to obtain all the data and keep the TIOBE index up to date. In order to compensate a bit for this, we ask a fee of 1,500 US$ for the complete data set. This might seem a lot of money but it is considered strategic data. The data set runs from June 2001 till today. It started with 25 languages back in 2001, and now measures more than 150 languages at least 10 times per month. The data are availabe in comma separated format. Part of the deal is that new data will be send to you for 1 extra year. Please contact sales@tiobe.com for more information.

  • Q: What happened to Java in April 2004? Did you change your methodology?

    A: No, we did not change our methodology at that time. Google changed its methodology. They performed a general sweep action to get rid of all kinds of web sites that had been pushed up. As a consequence, there was a huge drop for languages such as Java and C++. In order to minimize such fluctuations in the future, we added two more search engines (MSN and Yahoo) a few months after this incident.

  • Q: Why is YouTube used as a search engine for the TIOBE index?

    A: First of all, YouTube counts only for 7% of all ratings, so it has hardly any influence on the index. YouTube has been added as an experiment. It qualified for the TIOBE index because of its high ranking on Alexa. YouTube is a young platform (so an indicator for popularity) and there are quite some lectures, presentations, programming tips and language introductions available on YouTube.

'Computer Science' 카테고리의 다른 글

GSM : Overview of the Global System for Mobile Communications  (0) 2009.10.04
휴대폰 개발 프로세스  (1) 2009.09.27
파이썬 로보틱스 프로그래밍  (0) 2009.09.20
ePub 의 개요 [전자책 표준]  (0) 2009.09.03
WebOS  (0) 2009.08.30
[Home][Software][Curriculum][Hardware][Community][News][Publications][Search]

Pyro Software

Installation resources:

  • PyroInstallation - installation manual and download instructions
  • PyroLiveCD - New! Pyro Live Bootable CD. Just boot and run Pyro, Player, Stage, Gazebo, and more. Nothing to install.
  • PyroFAQ - Feedback and Frequently Asked Questions

Related resources:

For d0cumentation on using Pyro, please see PyroCurriculum

[Home][Software][Curriculum][Hardware][Community][News][Publications][Search]


CreativeCommons View Wiki Source | Edit Wiki Source | Mail Webmaster

http://pyrorobotics.org/?page=PyroSoftware

'Computer Science' 카테고리의 다른 글

휴대폰 개발 프로세스  (1) 2009.09.27
프로그래밍 언어 포럼 순위 (랭킹)  (1) 2009.09.27
ePub 의 개요 [전자책 표준]  (0) 2009.09.03
WebOS  (0) 2009.08.30
MS Windows에서 DevC++로 GTK프로그래밍하기  (0) 2009.08.17

3 September 2009 19:19:49


EPUB

[출처] MobileRead

ePub는 국제 디지털 출판 포럼(idpf)의 오픈 ebook 포럼에서 정의한 공개 포멧이다.

ePub는 XHTML과 XML 중에서 선택적인 스타일 쉬트(optional style sheet)에 기초하며,

ePub의 전신은 OEB(Open eBook) 표준이다.


- ePub의 정의

".epub"는 앞으로 널리 쓰일 디지털 책이나 출판물을 위한 XML 포멧의 확장자이다.

".epub"는 세가지 공개 표준으로 구성되는데, OPS (Open Publication Structure),

OPF (Open Packaging Format), 그리고 OCF (Open Container Format)이다.

".epub"는 출판사들이 고객에게 단 한개의 파일로 디지털 출판을 제공하여,

신뢰성있는 하드웨어/소프트웨어 방식으로 암호화한 디지털 책을 고객들에게 제공한다.


- ePub의 용례

ePub는 두가지의 파일로 서비스를 하는데, 소스파일 포멧과 최종 사용자 포멧이다. 이 이유는 파일들을

쉽게 제공하도록 모아서 담아 서비스하기 위함이다. 모아 담는 컨테니너는 일반적으로 zip 파일 포멧이다.


?
- ePub 리더 소프트웨어

Adobe Digital Editions - This reads Adobe DRM ePUB ebooks as well as non-DRM.
AZARDI - read ePUB and verify conformance.
Bookworm
Calibre - Windows, MacOS X and Linux
FBReader, Windows and more
OpenBerg Lector - Browser plugin
Stanza, Windows, MacOS X, and iPhone

- ePub 하드웨어

• Sony Reader PRS-700 - Sony Readers also support Adobe ADEPT (DRM) technology (EPUB/PDF)
• Sony Reader PRS-505 - Among other things, the V1.1 (Jul'08) firmware update added ePub support to the 505.
• Hanlin V3 and all its clones Bebook, EZ Reader, etc. See the full list - No DRM, A new firmware release (August 2009) uses ADE software that can support DRM
• JetBook - No DRM
• Bookeen Cybook Opus - Full support using ADE.

- ePub Creation software

• Adobe InDesign
• Atlantis Word Processor - can convert any TXT/RTF/DOC/DOCX d0cument to ePub.
• Calibre Click the "hammer" icon next to the search bar and set the output format to EPUB.
• CSS check tool
• DAISY Pipeline - creation and checking tools
• eCub - a simple to use EPUB and MobiPocket ebook creator
• ePUB check tool
• ePUB Tools - A collection of open source tools used to create and check ePUB
• EScape - an add-on for Open Office (ODT), not for commercial use.
• Convert uploads to ePUB at Feedbooks.com. You don't have to hit the "publish" button. Just edit your text, and download the ePub preview.
• OpenBerg Rector
• Python converter posted by MishaS - His latest version of oeb2epub is at his site
• Sigil is an editor (word processor) for directly changing or creating ePUB files.
• Stanza - converter for PC and Mac, typically strips formatting prior to conversion.
• Web2FB2 is a web site that will convert a URL to FB2 and ePUB format.

[edit] Specificatons
http://www.idpf.org/specs.htm contains the specifications for this format. In particular check the version 2.0 OPS and OPF specs and the version 1.0 OCF spec. The Informational d0cuments are also quite useful in understanding the intent and content.
[edit] OCF
A typical OCF is a zip file that might look like:
mimetype
META-INF/
container.xml
[manifest.xml]
[metadata.xml]
[signatures.xml]
[encryption.xml]
[rights.xml]
OEBPS/
Great Expectations.opf
cover.html
chapters/
chapter01.html
chapter02.html
… other HTML files for the remaining chapters …
[edit] mimetype
The first file in the ZIP Container MUST be a file by the ASCII name of ‘mimetype’ which holds the MIME type for the ZIP Container (i.e., “application/epub+zip” as a 20 character ASCII string; no padding, CR/LF, white-space or case change). The file MUST NOT be compressed nor encrypted and there MUST NOT be an extra field in its ZIP header.
[edit] OPF
The Open Packaging Format (OPF) Specification, defines the mechanism by which the various components of an OPS publication are tied together and provides additional structure and semantics to the electronic publication.
Specifically, OPF:
Describes and references all components of the electronic publication (e.g. markup files, images, navigation structures).
Provides publication-level metadata. Specifically it should include: dublin core formatted data
Specifies the linear reading-order of the publication.
Provides fallback information to use when unsupported extensions to OPS are employed.
Provides a mechanism to specify a declarative table of contents (the NCX).
An example:
<package version="2.0" xmlns="http://www.idpf.org/2007/opf"
unique-identifier="BookId">
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:opf="http://www.idpf.org/2007/opf">
<dc:title>Alice in Wonderland</dc:title>
<dc:language>en</dc:language>
<dc:identifier id="BookId" opf:scheme="ISBN">
123456789X
</dc:identifier>
<dc:creator opf:role="aut">Lewis Carroll</dc:creator>
</metadata>
<manifest>
<item id="intro" href="introduction.html"
media-type="application/xhtml+xml" />
<item id="c1" href="chapter-1.html"
media-type="application/xhtml+xml" />
<item id="c2" href="chapter-2.html"
media-type=application/xhtml+xml" />
<item id="toc" href="contents.xml"
media-type="application/xhtml+xml" />
<item id="oview" href="arch.png"
media-type="image/png" />
</manifest>
<spine toc="ncx">
<itemref idref="intro" />
<itemref idref="toc" />
<itemref idref="c1" />
<itemref idref="c2" />
<itemref idref="oview" linear="no" />
</spine>
</package>
[edit] OPS
The Open Publication Structure (OPS) Specification describes a standard for representing the content of electronic publications.
Specifically:
The specification is intended to give content providers (e.g. publishers, authors, and others who have content to be displayed) and publication tool providers, minimal and common guidelines that ensure fidelity, accuracy, accessibility, and adequate presentation of electronic content over various Reading Systems.
The specification seeks to reflect established content format standards.
The goal of this specification is to define a standard means of content description for use by purveyors of electronic books (publishers, agents, authors et al.) allowing such content to be provided to multiple Reading Systems and to insure maximum presentational equivalence across Reading Systems.
[edit] XHTML
A conforming OPS d0cument must support the following XHTML constructions.
XHTML 1.1 Module Name
Elements (non-normative)
Notes
Structure
body, head, html, title
the default rendering for body is consistent with the CSS property page-break-before having been set to right (which behaves like always on one-page Reading Systems), but may be overridden by an appropriate style sheet declaration.
Text
abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var
The optional attribute cite may be used in blockquote, q, del and ins to provide a URI citation for the element contents. Reading Systems are not required to process or use the referenced URI resource, whether or not the resource is listed in the Manifest.
Hypertext
a
Reading Systems may use or render a URI referenced physical resource not listed in the Manifest (i.e., it is not a component of the Publication), but they are not required to do so.
List
dl, dt, dd, ol, ul, li

Object
object, param
The object element is the preferred method for generic object inclusion. When adding objects whose data media type is not drawn from the OPS Core Media Type list or which reference an object implementation using the classid attribute, the object element must specify fallback information for the object, such as another object, an img element, or descriptive text.
Presentation
b, big, hr, i, small, sub, sup, tt

Edit
del, ins

Bidirectional Text
bdo

Table
caption, col, colgroup, table, tbody, td, tfoot, th, thead, tr

Image
img
The inline element img should only be used to refer to images with OPS Core Media Types of GIF (http://www.w3.org/Graphics/GIF/spec-gif89a.txt), PNG (RFC 2083), JPG/JFIF (http://www.w3.org/Graphics/JPEG) or SVG (http://www.w3.org/TR/SVG11/). The required URI attribute, src, is used to reference the image resource, which must be listed in the Manifest.
The required alt attribute should contain a brief and informative textual description of the image. This text may be used by Reading Systems as an alternative to, or in addition to, displaying the image. The text is also an acceptable fallback for an img with src referencing a non-OPS Core Media Type for which no viable fallback was found in the manifest.
Client-Side Image Map
area, map

Meta-Information
meta

Style Sheet
style
The type attribute of the style element is required and must be given the value of text/css or the deprecated text/x-oeb1-css.
Style Attribute (deprecated)
style attribute

Link
link
The link element allows for the specification of various relationships with other d0cuments. Reading Systems must recognize external style sheet references specified via the href attribute and the associated rel attribute (for the values rel="stylesheet" and rel="alternate stylesheet".)
Base
base


[edit] Relationships
Relationship to NVDL
This specification uses the NVDL language (see http://standards.iso.org/ittf/PubliclyAvailableStandards/c038615_ISO_IEC_19757-4_2006(E).zip) as a means to unambiguously define the interaction between the various schemas used in this specification. NVDL allows for interaction and validation between various XML schema languages. See Appendix A for a normative NVDL definition of OPS.
This specification does not require the use of NVDL tools to validate OPS d0cuments, although such tools are available and may be used for validation.
Relationship to XHTML and DTBook
This specification recognizes the importance of current software tools, legacy data, publication practices, and market conditions, and has therefore incorporated certain XHTML 1.1 Document Type Modules and DTBook as Preferred Vocabularies. This approach allows content providers to exploit current XHTML and DTBook content, tools, and expertise.
To minimize the implementation burden on Reading System implementers (who may be working with devices that have power and display constraints), the Preferred Vocabularies do not include all XHTML 1.1 elements and attributes. Further, the modules selected from the XHTML 1.1 specification were chosen to be consistent with current directions in XHTML.
Any construct deprecated in XHTML 1.1 is either deprecated or omitted from this specification; CSS-based equivalents are provided in most such cases. Style sheet constructs are also used for new presentational functionality beyond that provided in XHTML.
Relationship to CSS
This specification defines a style language based on CSS 2. (Note that the CSS 2.1 specification is currently still at "Working Draft" status.) The style sheet MIME type text/x-oeb1-css has been deprecated in favor of text/css.
Relationship to XML
OPS is based on XML because of its generality and simplicity, and because XML d0cuments are likely to adapt well to future technologies and uses. XML also provides well-defined rules for the syntax of d0cuments, which decreases the cost to implementers and reduces incompatibility across systems. Further, XML is extensible: it is not tied to any particular type of d0cument or set of element types, it supports internationalization, and it encourages d0cument markup that can represent a d0cument’s internal parts more directly, making them amenable to automated formatting and other types of computer processing.
Reading Systems must be XML processors as defined in XML 1.1. All OPS Content Documents must be valid XML d0cuments according to their respective schemas.
Relationship to XML Namespaces
Reading Systems must process XML namespaces according to the XML Namespaces Recommendation at http://www.w3.org/TR/xml-names11/. For example:
xmlns:ops="http://www.idpf.org/2007/ops"
[edit] Tips
It is possible to make an eBook that conforms to the standard by placing the entire book contents in one XHTML file but the performance will be impacted by this decision. For best performance a standard size book should be divided into several files as the full file needs to be loading into memory at once. This is usually accomplished by separating the files by chapter.
Some mobile devices cannot handle large ePUB files. Generally this is caused by having an XHTML file that is too large. If the file can be expanded the large XHTML file may be able to be broken into multiple files.
The ePub file format has proper support for TOC, through the use of TOC.NCX files. Not all reader applications support this currently. This is d0cumented in the DTBook standard.
Make sure all tags are complete (no dangling tags). htmltidy does a great job here
Get rid of as many tables as you can! A lot of these CHM type files put the entire content of the page in one table and that causes tons of problems
"normal" tables tend to get truncated in the reader due to being too wide. Convert these tables to some intelligent lists with <hr/>'s around them
Play with the CSS to get the colors cleaned up. A lot of the "color" gets translated to light grey and it sucks. Best just to change everything to black that you can
<pre> blocks of code can go off the page as well. Use the CSS to shrink their font size and, at worst, reformat the blocks to keep them into a 70 character width at 6pt.

'Computer Science' 카테고리의 다른 글

프로그래밍 언어 포럼 순위 (랭킹)  (1) 2009.09.27
파이썬 로보틱스 프로그래밍  (0) 2009.09.20
WebOS  (0) 2009.08.30
MS Windows에서 DevC++로 GTK프로그래밍하기  (0) 2009.08.17
임베디드 OS란 무엇인가  (0) 2009.08.15

WebOS

web os라는 용어는 낯설지만 개념은 그리 낯설지 많은 않을 것이다.HTML, JAVA, HTTP등의 프로토콜을 이용해서, 네트워크 상에서 구동되는 Network Computer 에 대한 구상은 10년전인 1996년부터 시작되었다. 용어에 있어서 차이는 있지만 네트워크 상에 데이터를 저장하고 처리한다는 점에 있어서, NC와 web os는 추구하는 바가 매우 비슷하다 할 수 있다.

NC를 완성하기 위한 많은 노력이 있었고, 특정 분야에 도입되기도 했지만 일반인과는 거리가 먼 실패한 제품이였다. 개념은 훌륭했지만 느린 하드웨어와 네트워크 속도, 무거운 가상머신과 시스템에 대한 불충분한 이해와 인프라의 미비 때문에 성장하지 못했었다.

그러던 것이 구글 데스크탑과 윈도우 live Desktop 으로 가능성이 주목받고 있다. 이들 WebOS의 구상은 다음과 같다.

webos.png

Browser는 Web Server를 통해서 인증과 같은 필요한 절차를 거치고, 가상화된 Storage에 자신의 정보를 저장한다. 이들 정보는 Web Service 형태로 다시 서비스 된다. 내부적으로는 분산처리 System에서 개인정보와 Sotrage의 정보를 분석해서 개인화된 정보를 서비스 하고, 정보를 색인해서 빠르게 검색할 수 있도록 한다.

Gadget은 브라우저와 독립적으로 실행되어서 웹서비스를 이용하는 조그만 소프트웨어로 자신만의 웹 데스크탑 환경을 구축하게 해준다. 또한 시간이 충분하다면, 자신만을 위한 혹은 공유가능한 유용한 웹애플리케이션의 제작이 가능하다.

이를 가능하게 해주는 기술들로는 아래와 같은 것들이 있다.
  • HTTP(:12)
  • Ajax(:12)/Javascript
  • HTML(:12)
  • 가상화 기술 / 분산처리 기술

Web OS를 긍정적으로 보는 이유

NC가 실패했기 때문에 Web OS가 실패할 것이란 얘기를 많이 듣는다. 가장 큰 이유는
  1. 느리다
  2. 쓸만한 응용이 없다.
  3. 대중에게 파고들만한 인프라가 구축되어있지 못했다.(시대를 앞선 기술)
정도가 될 거 같다.

1번 문제에 대해서는 웹 OS의 개념에 대해서 확실해 해둘 필요가 있는데, WebOS는 데스크탑의 모든 것을 포괄하지 않는다. 기존의 Web환경과 데스크탑영역의 일부분을 웹환경의 영역으로 확대시키겠다는 개념이다.

게임등과 같이 반응과 처리속도가 중요한 영역은 당연히 기존 데스크탑영역에 그대로 머무르게 될 것이다. 그러나 그렇지 않은 부분들 중 데이터가 공유되거나 가상화 되었을 때, 이득을 볼 수 있는 많은 응용은 WebOS 영역으로 넘어갈 것이다.

만들어진 데이터를 자신의 PC에서만 다루던 시대는 이미 지났다. 이동성이 중요해졌으며, 동일한 데이터를 PC, 인터넷에 연결된 다른 컴퓨터, 핸드펀과 같은 소형 모바일기기에서 보고/공유할 수 있어야 한다. 이건은 먼 미래의 요구가 아니며, 지금 요구되어 지는 기능들이다. 이에 웹은 최상의 환경을 제공한다.

문서작성을 예로 들어보자. googledocs를 사용해 보면 알겠지만 딱히 느리거나 크게 불편하다는 생각이 들지 않는다. 복잡한 문서를 작성하기엔 속도와 기능상의 문제가 있겠지만 80%이상을 차지할 거라고 생각되는 간단한 문서 (예를 들어 블러깅을 위한)를 생성하는 데에는 문제가 없다. 만들어진 문서는 가상화된 Storage에 저장이 되기 때문에, 어떤 컴퓨터에서라도 브라우저만 설치되어 있다면 접근할 수 있으며, 웹과 다른 블로깅시스템으로의 출판, 검색등이 자유롭다. 자신의 데스크탑의 검색 결과를 네트워크 상에서 확인할 수 있는 서비스도 추가되어 있으며, 결국 웹에서 작성한 모든 컨텐츠가 기기에 관계없이 편집/수정/출판/검색/공유 할 수 있도록 될 것이다.

그 밖의 웹에서 다루는 데이터는 그 특성상, 반응속도가 중요하지 않는 경우가 많다. RSS 정보를 본다거나, 문서/이미지/동영상/블로문서/메일 검색, 추천정보확인 모두 반응과 속도가 중요한 응용들이 아니다.

쓸만한 응용이 없다는 의견에 대해서라면, RSS 피드정보, 검색, 메일 등의 웹정보가 가장 유용한 정보가 된 현시점에서는 문제가 되지 않을 거라 생각한다. 많은 유저가 게임을 하는 시간을 빼고는 대부분의 시간을 RSS 확인과 검색, 몇 개의 이미지를 포함한 간단한 문서작성등에 보내고 있다. 웹데이터를 잘 다루는 소프트웨어가 쓸만한 응용인 셈이다. 올블러그의 10개의 인기 블러그를 보여주는 응용이 쓸만한 응용이 된 세상이다. 여기에 더해서 웹OS는 가상화 기술을 통해서 모든 기기에서 데이터를 공유할 수 있는 가능성을 열어두고 있다.

http://www.eyeos.org 를 보기 바란다. 아직 부족하긴 하지만, WebOS의 방향을 가늠해 볼 수 있을 것이다.

eyeos.png

기업에서의 WebOS 의 사용

WebOS는 기업에서도 지식관리시스템의 구축을 위한 좋은 환경을 제공한다. 웹으로 묶여진 가상의 공간에서 의견과 생산된 정보를 저장하고 공유/검색 할 수 있는 것이야 말로 지식관리 시스템의 핵심이니까 말이다. 이러한게 가능하려면 물론 회사의 정보가 외부의 저장장치에 저장이 된다는 데에서 오는 부담감을 해결할 수 있는 신뢰도가 확보되어야 할것이다. 우리나라는 아직 요원해보이지만, 많은 회사들이 위키를 중심으로 하는 지식관리 시스템을 구축하고 있으으며 이를 위한 위키호스팅 업체도 영업을 하고 있는 상황이다.

WebOS는 이러한 것들을 망라해서 최적의 지식관리 시스템을 만들어 줄 수 있다. 일종의 회사 인트라넷 자원관리를 위한 호스팅 서비스라고 부를 수 있을 것 같은데, 구글은 이미 기업용 호스팅 서비스를 선보이고 있다. 아직은 베타이긴 한데, 2GB의 스토리지를 할당하고, 이 한도내에서 자사의 서비스인 Gmail, Google Calendar, Google Talk, Page Creator 등의 웹서비스를 사용할 수 있도록 하고 있다. 여기에 조만간 위키시스템이 추가되고, 이들 웹서비스들이 구글 테스크탑환경에 맞도록 조절된다면 필요한 요소가 모두 갖추어진 기업용 WebOS가 탄생하게 될 것이다. 위키와 관련된 내용은 [http]구글 잣스팟 인수 뉴스를 읽어보기 바란다.

구글 서비스 관련 문서

이름
제목
변경일
크기
구글 Adsense 연구
2007/01/09 11:46
958
구글 애드워즈 사용기
2007/01/26 19:44
3575
더 좋은 구글 검색방법
2007/02/01 12:00
3602
구글 Blogger BETA
2007/01/09 11:46
59
Google Code Hosting
2007/01/09 11:46
2916
Google source code 검색
2007/01/09 11:46
1030
구글개인화 검색 테스트
2007/05/28 22:29
706
구글 개인화 검색 - google custom search
2007/06/04 23:44
3306
Google's Disk Failure Experience
2007/11/06 10:29
4476
Google Docs 자유 그리기 기능을 써보고
2009/03/30 00:15
2653
도메인 평가
2007/01/09 11:46
707
구글 가제트
2007/01/09 11:46
1359
구글맵 API를 이용한 Map Service
2009/07/01 14:49
19476
구글 Web Toolkit
2009/07/05 21:03
1158
Google Trend로 알아보는 Blog와 Wiki의 미래
2007/07/04 22:19
4167
구글맵으로 둘러보는 자전거 산책로
2009/03/17 22:22
2140
구글 News Bar 서비스
2007/02/12 14:14
2002
구글 Docs
2007/01/09 11:46
50
구글 PageRank
2008/10/24 16:48
8161
Web2.0에서의 승자독식 ?
2007/05/07 13:18
2567
Google Picasa
2007/01/09 11:46
4697
구글 인기검색어
2007/01/09 11:46
511
Google Reader
2007/01/09 11:46
55
구글 논문 검색
2007/01/09 11:46
325
Google Search API
2007/02/13 01:28
2939
Google AJAX Search API 개발자 가이드
2007/02/12 18:37
3318
구글 테마 적용
2007/03/23 21:33
1893
비쥬얼 페이지 랭크
2007/01/09 11:46
678
웹2.0과 저작권 - 일등만이 살아남는 Web2.0 세상
2007/07/06 23:16
5445
사이트 관리자를 위한 구글 서비스
2007/01/09 11:46
87
WebOS의 미래
2007/01/09 11:46
5447
웹 2.0의 허상
2007/05/10 01:55
31140
왜 구글에 열광하는가
2007/06/20 01:31
8676
구글 Map 서비스의 가능성
2007/01/09 11:46
66
구글을 이용한 나만의 검색엔진 만들기
2007/01/09 11:46
78
google earth 와 google map의 차이점
2009/03/31 00:11
151
이글루스 블로그에 애드센스 달기
2007/04/11 21:32
1965
구글 Gadget
2007/02/20 20:06
9255
한국형 Google 개인화 홈페이지
2007/05/05 20:34
1831

'Computer Science' 카테고리의 다른 글

파이썬 로보틱스 프로그래밍  (0) 2009.09.20
ePub 의 개요 [전자책 표준]  (0) 2009.09.03
MS Windows에서 DevC++로 GTK프로그래밍하기  (0) 2009.08.17
임베디드 OS란 무엇인가  (0) 2009.08.15
[summary] linux device driver  (0) 2009.08.12

MS-Window에서 Dev-C++(DevCpp) 로 GTK+ 으로 프로그래밍 하기

C도 초보고 gtk+도 초보입니다. 하지만 셋팅을 하는 동안의 과정을 간략하게 정리하고자 합니다.

Dev-C++은 설치되었다는 전제하에서 설명하겠습니다. (참고로 Dev-C++의 주소는 http://bloodshed.net/index.html 입니다.)

Dev-C++을 한글환경에서 설명할 것이기 때문에 한글환경이 아니라면, 메뉴의 ‘Tools’ -> ‘Environment Options’ 에서 ‘Interface’ 탭에 있는’ Language’에서 ‘Korea(한국어)’를 선택하세요.

1. GTK+ 설치를 위한 사전 작업

GTK+는 다른 라이브러리들과 의존성을 가지기 때문에 사전에 의존성을 가지는 라이브러리들을 설치해주어야 합니다.

라이브러리 목록은 다음과 같습니다.

· Glib

· atk

· Pango

· zlib

· libpng

· libpixman

· Cairo

위 7개의 라이브러리를 먼저 설치해 주어야 합니다. 마지막에 있는 Cairo는 바로 위 두개(libpng, libpixman)에 의존성을 가지므로 Cairo를 설치하기 전에 두개의 패키지를 먼저 설치하여야 하고, libpng는 zlib에 의존성을 가지므로 zlib를 먼저 설치해야 합니다. 일단 이부분은 접어두고 총 7개의 라이브러리를 먼저 설치해야 합니다. 아래 부분에서 자세히 설명을 할테니 넘어갑시다.

설치를 위해 Dev-C++에서 제공하는 패키지 업데이를 진행하면 됩니다.

메뉴의 ‘도구’ -> ‘프로그램 업데이트’를 선택하면 아래와 같이 하나의 창이 뜹니다.



‘Select devpak server’에서 ‘Devpaks.org Community Devpaks’를 선택합니다.

그리고, 아래의 ‘Check for updates’를 클릭합니다. 그려면 프로그래스바가 진행되고 ‘Available updates list’에 업데이트할 수 있는 목록이 작성됩니다. 그리고, ‘Check for updates’는 ‘Download Selected’로 바뀌게 됩니다.

설치순서는 아래와 같습니다.

1. zlib

2. libpixman, libpng

3. atk, cairo, glib, pango

순서대로 각 항목에 체크를 하고 ‘Download Selected’를 눌러주면 됩니다. (한 항목에 두개 이상의 패키지가 있으면, 체크란에 두개 다 체크하고 ‘Download Selected’를 눌러주면 됩니다.)

간단한 대화창과 함께 설치가 완료되면, 이제 준비작업은 끝났습니다. (사실 준비작업이라 말하기는 좀 그렇지만...)

2. GTK+ 설치

이제 gtk+를 체크하고 설치하면 됩니다.(Download Selected)

이제 gtk+를 프로그래밍을 하기 위한 준비는 끝났습니다. 그런데, 실행파일을 만들기 위해서는 dll 파일들이 필요합니다. 이 파일들을 gimp에서 다운받을 수 있습니다.

윈도우를 위한 gimp의 주소는 http://gimp-win.sourceforge.net/ 입니다. 다운로드 주소는 http://gimp-win.sourceforge.net/stable.html 입니다. 그런데...

GTK+ 2 Runtime Environment를 다운받아야 하는데, 목록이 두개가 있습니다.

저는 XP환경이라 위에 있는 (version 2.10.6 for Windows 2000 and newer)을 다운받았지만, 압축을 풀려니 계속 에러가 나네요. 그래서 어쩔 수 없이 그 아래에 있는 (version 2.6.10-20050823, for Windows 98/ME and NT4)를 다운받았습니다. 이걸 다운받고 압축풀고 설치를 시작하면 간단한 대화상자가 나오고, 설치를 하면됩니다.

3. GTK+ 프로그래밍 해보기

메뉴에서 ‘파일’ -> ‘새로 만들기’ -> ‘프로젝트’ 를 선택합니다. 그러면 아래와 같이 창이 뜹니다.


Basic 탭에서 GTK+ Application, 프로젝트명을 적당히 적어주고 언어는 C를 선택합니다. 그리고 확인을 누르면 GTK+ 프로그래밍을 할 수 있게 소스창이 구성됩니다.

메뉴에서 ‘실행’ -> ‘컴파일’ 그러면 컴파일이 되고 실행파일이 만들어집니다. 이제 GTK 프로그램이 완성되었습니다.

이제 http://gtk.org에서 튜토리얼을 보면서 이것저것 공부하면 됩니다. ^^

(그런데, ‘실행’ -> ‘실행’을 눌러주면 먹통일 때가 있습니다. 소스를 컴파일 한 곳에서 가서, 실행파일을 어떤 dll파일이 필요하다는 에러메시지가 뜹니다. 이때를 위해 조금전에 GTK+ Runtime Environment를 설치한 것입니다. ‘Program Files’- > ‘Common Files’ -> ‘GTK’ -> ‘2.0’ -> ‘bin’ 폴더에 보면 많은 dll파일들이 있습니다. 그곳에서 dll 파일을 찾아 실행파일이 있는 곳에 복사하고 실행파일을 더블클릭하면 이제 실행이 됩니다. 패스를 걸어주셔도 됩니다.)

[출처] MS윈도우에서 Dev-C++로 GTK+ 프로그래밍 하기|작성자 매지구름

'Computer Science' 카테고리의 다른 글

ePub 의 개요 [전자책 표준]  (0) 2009.09.03
WebOS  (0) 2009.08.30
임베디드 OS란 무엇인가  (0) 2009.08.15
[summary] linux device driver  (0) 2009.08.12
Getting started with an embedded Linux system emulator  (0) 2009.08.09
출처 : http://wedcum.egloos.com/

임베디드 OS에는 어떤 것들이 있는가
임베디드 시스템을 개발하려면 개발하려는 시스템이 어떠한 기능을 수행하는지 그 복잡도는 어느 정도인지 실시간성을 요구하는지 개발기간은 얼마나 필요한지 등에 따라 적당한 임베디드 OS를 선택하여 적용해야 한다. 따라서 그러한 임베디드 OS에는 어떠한 것들이 있으며 각각의 특징이 무엇인지 알 필요가 있다. 현재 나온 임베디드 OS는 그 종류가 무수하게 많은 편이다. 데스크톱 시장처럼 특정 OS가 임베디드 OS 시장을 점유하는 것이 아니기 때문이다. 수많은 임베디드 OS 중에서 주류를 이루고 있는 상용 RTOS, 윈도우 CE 닷넷, 윈도우 XP 임베디드, 임베디드 리눅스에 대해서 알아보겠다.

상용 RTOS
RTOS는 그 종류만 해도 수를 헤아리기 힘들다. RTOS는 실시간 처리에 대한 강력한 지원과 통합 개발 및 디버깅 환경을 지원한다. 대표적으로 화성 착륙선인 패스파인더(PathFinder)와 혼다에서 만든 로봇인 아시모(ASIMO)의 운영체제로 쓰인 윈드리버(WindRiver)의 VxWorks, ISI에서 개발해서 지금은 윈드리버에 통합된 pSOS, Mentor Graphics의 VRTX 등이 있으며 교육용으로 만들어진 uC/OS-II가 있다. 이들 RTOS는 선점형 멀티태스킹을 지원하며 각 태스크들은 우선순위를 가지고 있어 높은 우선순위를 가지는 태스크들이 먼저 실행되는 구조를 가지고 있다. 또한 통합개발환경과 디버깅 툴을 개발하여 개발자들에게 용이한 개발환경을 지원하고 있다. 단점이라고 하면 이들 RTOS들이 대부분이 상용이라 라이선스 비가 만만치 않다.

pSOS
ISI에서 1980년대에 개발한 pSOSystem은 우리나라의 여러 업체가 채택해서 사용하고 있는 RTOS로 삼성전자가 pSOS+ 개발에 참여해 라이선스를 갖고 있어 잘 알려져 있다. 삼성전자의 휴대폰에 사용되어 왔으며, 각종 통신장비와 네트워크 장비에서 사용되고 있다. pSOSystem은 커널을 중심으로 해서 여러 개의 소프트웨어 컴포넌트들로 구성되어 있다. 이들 소프트웨어 컴포넌트들은 각각의 독립적인 모듈로 되어 있으며 통합개발환경 툴로 pRISM+을 제공하고 있다.
pSOSystem은 멀티태스킹 RTOS로 각 태스크들은 우선순위를 가지고 있어 우선순위가 높은 태스크들의 작업 수행이 먼저 이루어진다. 따라서 선점형 스케쥴링 방식을 따른다고 볼 수 있다. 만일 각 태스크들이 같은 우선순위를 가진다면 스케쥴링 방식은 라운드로빈(Round-robin) 방식으로 바뀌게 된다. 태스크의 수는 총 256개이다. 그리고 태스크 관리, 세마포어(semaphore), 메시지 큐, 시간 관리 및 타이머, 이벤트 및 비동기 시그널, 에러 처리, 동적인 메모리 저장관리, 다른 태스크들로부터의 코드나 데이터 보호 등의 서비스를 지원한다. 여러 개의 다른 실행 모드를 가지고 있는 CPU를 위해서 사용자 모드와 슈퍼바이저 모드를 제공하고 있다.
pSOSystem은 실시간 멀티태스킹 커널을 중심으로 여러 개의 소프트웨어 컴포넌트와 라이브러리를 두고 있다. 이런 컴포넌트와 라이브러리는 선택적으로 사용될 수 있다. 하부 구조에는 디바이스 드라이버와 칩과 각종 디바이스의 정보를 담고 있는 BSP(Board Support Package)가 있다. BSP를 따로 구별하는 이유는 만일 하드웨어가 변경될 경우 시스템 프로그램에 큰 변경없이 BSP만 수정하여 쉽게 처리할 수 있기 때문이다. 따라서 전체적으로 정리해 보면 BSP와 디바이스 드라이버의 바탕 위에 커널과 기타 필요한 컴포넌트들을 링크하고, 다시 그 위에 사용할 각종 태스크와 응용 프로그램을 제작하여 사용하는 것이다. pRISM+는 pSOSystem 개발자가 좀더 용이한 개발을 위해 소스 코드 분석을 위한 툴과 컴파일러, 링커, 디버깅할 수 있는 툴을 제공하는 통합개발환경이다.

VxWorks
윈드리버의 RTOS인 VxWorks는 pSOSystem과 유사한 점이 많다. pSOSystem이 통합개발환경으로 pRISM+를 제공한다면 VxWorks는 토네이도를 제공한다. VxWorks의 커널인 마이크로커널은 선점형 멀티태스킹이며 총 태스크의 단계는 256, 스케쥴링 방식도 높은 우선순위를 가지는 태스크가 먼저 실행하는 방식을 지원한다. 만일 같은 우선순위를 가진다면 라운드로빈 방식의 스케쥴링을 이용하는 것도 pSOSystem과 유사하다. 또 하나 pSOSystem이 여러 개의 컴포넌트로 되어 있다고 하면 VxWorks는 200개 가량이 모듈을 지원하는 형식으로 되어 있어 개발자는 이들 필요한 모듈만 사용해서 시스템에 맞는 운영체제를 구성할 수 있다. VxWorks는 현대의 RTOS들이 지원하는 거의 모든 서비스를 지원하고 있다. 태스크간의 통신을 위해 세마포어와 메시지 큐, 공유 메모리, 소켓, 시그널 등을 제공하고, 표준 TCP/IP 네트워킹과 ROM이나 로컬 디스크, 네트워크로 부팅이 가능하게 되어 있다.
VxWorks의 구조는 크게 하드웨어에 의존하는 BSP, 디바이스 드라이브 영역과 하드웨어에 의존하지 않는 커널과 그에 따른 모듈, 그리고 애플리케이션 프로그램으로 나뉜다. 이것은 pSOSystem과 매우 유사한 부분이다. VxWorks의 토네이도는 교차 개발환경을 지원하는 통합개발환경이다.

윈도우 CE 닷넷과 윈도우 XP 임베디드
마이크로소프트(이하 MS)는 임베디드 시장에 대한 공략을 위해 1996년 윈도우 CE를 발표했다. MS에서 제작된 기존의 윈도우 인터페이스에 모바일 네트워크 기능을 강화해 가전제품, PDA, 셋톱박스 등에 주로 사용되고 있다. 적외선 통신, 웹 브라우징 기능 이외에도 편리한 개발환경을 가지고 있으며 UI가 기존의 윈도우와 매우 유사하게 제작돼 있어 대부분의 사용자들은 별도의 학습없이도 바로 사용이 가능하다. 또한 윈도우 CE 계열의 PDA는 흑백 및 컬러 디스플레이가 가능하며 동영상, WAV, MP3 등 멀티미디어 파일의 재생이 가능하여 PDA의 엔터테인먼트 기기화를 가져왔다.
또한 PC용의 윈도우 OS나 각종 오피스 프로그램들과 완벽한 호환이 가능해 기존의 데스크톱이나 노트북에서 가능하던 각종 애플리케이션들을 PDA에서도 그대로 사용할 수 있다는 이점이 있다. 그러나 제한적인 하드웨어를 가진 임베디드 시스템에 너무 많은 기능을 구현하려 했기 때문에 느린 실행 속도와 불편한 UI를 초래했다.
이를 개선해 MS는 2000년 4월 윈도우 CE 3.0을 개발하고 기존의 윈도우 CE와는 전혀 다른 것이라는 것을 강조하기 위해 그것을 포켓PC(PocketPC)라고 명명했다. 포켓PC의 등장으로 기존 윈도우 CE에서 보여주었던 수행속도의 저하와 비효율적인 하드웨어의 활용 등의 문제점들이 보완됐다. 윈도우 PC는 사운드와 동영상 재생 및 컬러 디스플레이 구현 등 다양한 멀티미디어 기능을 기본적으로 제공하며 PC와의 호환성이 뛰어나다. 또한 포켓 인터넷 익스플로러를 기본으로 내장해 모바일 인터넷을 실현했다. 게다가 데스크톱과 거의 흡사한 UI를 갖춤으로써 윈도우에 익숙한 사용자들을 쉽게 끌어들이고 있다. 그럼에도 불구하고 PDA 업계에서 윈도우 CE의 시장점유율은 팜 OS에 미치지 못했다. 하지만 유명 PDA 업체들이 윈도우 CE 채용 제품들을 대거 출시함에 따라 점유율은 계속 증가 추세에 있다.
MS는 윈도우 CE 3.0의 소스 코드를 공개한 후 2002년 초 코드명 탈리스커(Talisker)로 알려졌던 윈도우 CE 닷넷과 윈도우 XP 임베디드를 공식 발표했다. MS는 윈도우 CE 닷넷을 Non-X86 프로세서 계열이거나 실시간이 요구되는 시스템에 대해서 권고를 하고 있으며 PC 운영체제인 윈도우 XP 프로페셔널의 컴포넌트 버전인 윈도우 XP 임베디드는 네트워킹과 서버 기능을 수행하는 시스템 개발에 권고를 하고 있다.

임베디드 리눅스
리눅스는 초기 PC나 서버급 시스템에 포팅돼 사용되기 시작하다 현재는 임베디드 시스템으로도 많이 사용된다. 리눅스는 상용 임베디드 OS보다는 실시간적 요소를 충족하지 못하고 윈도우 CE보다는 개발환경이 좋지는 않지만, 오픈소스에 라이선스 비용이 없기 때문에 커널 크기를 줄여 다양한 임베디드 시스템의 개발에 유리하다. 리눅스는 소스를 공개하는 오픈소스 정책을 따르는 관계로 관련 개발자가 세계 곳곳에 있어 현지의 응용 프로그램을 개발할 수 있는 개발자 층이 넓다는 것이 다른 OS들과 구별되는 큰 장점이다. 이에 따라 리눅스를 채용한 임베디드 시스템은 다른 제품에 비해 가격 경쟁력이 우수하고 다양한 응용 프로그램의 개발이 가능할 것으로 기대된다. 임베디드 리눅스는 소스 공개와 아울러 안정성, 신뢰성 및 성능의 확보에 따라 활용도가 급격히 증대되고 있으며, 레드햇, 몬타비스타, 리니오 등이 임베디드 리눅스 개발 및 기술 지원 사업에 주력하고 있다.
그러나 임베디드 리눅스는 열악한 개발환경에 따른 개발기간에 대한 부담과 라운드로빈 방식의 스케쥴링을 하므로 실시간 시스템에는 적합하지 않다는 문제점을 가지고 있다. New Mexico Tech에서 기존 리눅스 커널에 실시간 기능을 추가한 RT-Linux를 개발했으며 또한 오픈소스 진영에서는 임베디드 리눅스를 기반으로 한 표준화를 통해 시장 확대를 도모중인데, 2000년에 애질런트, 알카텔, HP, IBM, 윈드리버, ARM, 모토롤라 등이 참여하는 세계 최대 규모의 임베디드 리눅스 컨소시엄(ELC: Embedded Linux Consortium)이 결성되어 임베디드 리눅스 및 실시간 운영체제 API 표준인 EL/IX(Em bedded Linux based on POSIX)를 기반으로 플랫폼 표준화를 추진하고 있다.
임베디드 운영체제 시장은 전통적인 RTOS 중심에서 다기능 임베디드 OS 중심으로 발전하는 추세에 따라 VxWorks, pSOS 등의RTOS의 시장 성장율이 둔화되고 있으며, 전용 실시간 임베디드 시스템에서 높은 시장 점유율을 보였던 VxWorks, pSOS, VRTX와 같은 전통적인 RTOS는 2001년을 기점으로 시장 점유율이 하락하고 있다. <그림 1>에서와 같이 2003년에는 임베디드 리눅스, 임베디드 윈도우 CE 및 팜 OS 등의 임베디드 OS 시장이 기존의 RTOS 시장을 능가할 것으로 예측된다. 전통적인 RTOS의 시장 점유 하락으로 임베디드 OS 시장에서는 MS와 임베디드 리눅스가 시장 선점을 위해 치열한 각축을 벌일 것으로 예상된다.

임베디드 시스템 개발 환경
임베디드 시스템을 개발하기 위해선 기본적으로 <그림 2>와 같은 요소들이 갖춰져 있어야 한다. ‘호스트’는 임베디드 시스템 개발을 위한 컴퓨터를 말하며, ‘타겟’은 실제 임베디드 시스템이 설치된 개발하고자 하는 하드웨어를 말한다. 호스트에는 개발을 위한 개발 툴, 개발된 응용 프로그램을 임시로 수행해 볼 수 있는 타겟 시뮬레이터, 타겟과 연결되어 타겟에 개발된 이미지를 업로드하거나 타겟에 반응하는 디버그 에이전트를 통해 원격 디버깅을 할 수 있게 하는 타겟 서버가 설치돼 있다. 또한 타겟에는 호스트에서 만들어져서 설치된 여러 컴포넌트가 존재하는데 타겟을 부팅하기 위한 부트 로더와 커널, 그리고 임베디드 응용 프로그램이 존재하게 된다. 호스트에 설치된 개발 툴에는 타겟에서 수행될 수 있는 바이너리를 생성하는 크로스 컴파일러가 존재하며 그 밖에 오류를 검색해 주는 디버거 등으로 이뤄져 있다.

임베디드 시스템 개발 과정
임베디드 시스템 개발 과정은 대략적으로 부트로더 개발, 커널 및 파일 시스템 개발, 응용 프로그램 개발의 세 단계로 볼 수 있다.

부트 로더 개발
부트 로더는 타겟 보드에 전원이 인가되면 부트 롬으로부터 가장 먼저 수행되는 프로그램이다. 보통 부트 로더는 OS의 커널을 로드하는 순수 로더로서의 기능뿐만이 아니라 현재 레지스터나 메모리 값, 버스 상태 등을 살펴볼 수 있는 모니터 기능, 기초적인 네트워크 모듈을 내장해 네트워크를 통한 커널을 다운받아서 커널 로드를 할 수 있는 기능을 포괄하고 있다.부트 로더는 보통 부트 롬에 내장되어 있으며 부트 로더를 새로 작성하여 타겟에 설치하려면 호스트와 JTAG 인터페이스 혹은 기타 인터페이스를 통하여 설치할 수 있으며 이외의 방법에는 롬 라이터를 이용하여 롬에 구워서 설치할 수 있다.
대부분 상용 임베디드 OS에서는 부트 롬 부분을 앞서 잠깐 언급한 BSP라 불리는 패키지의 일부분으로 규정하고 있다. 반면 임베디드 리눅스의 경우는 규격화된 BSP가 존재하지 않으므로 하드웨어 벤더가 리눅스용 BSP를 제공하지 않을 경우 부트 롬 부분을 각 하드웨어 플랫폼에 맞게 작성해야 한다.

커널 및 디바이스 드라이버 및 파일 시스템 개발
커널 및 디바이스 드라이버의 개발은 호스트의 임베디드 시스템 개발 툴에서 이뤄진다. 개발을 위해서는 개발자가 먼저 시스템에 대한 하드웨어 사양을 숙지해야 하며 이를 바탕으로 커널 및 디바이스 드라이버를 설정하게 된다. 이렇게 생성된 커널 및 디바이스 드라이버들은 부트 롬과 같이 하나의 이미지 파일 형태로 되어 부트 롬에 저장되거나 별도의 저장 장치에 파일 시스템을 통한 파일 형태로 구현된다. 만일 부트 롬의 용량이 작거나 기타 저장장치가 없는 경우 부트 로더에서 네트워크 모듈을 통해 별도의 서버로부터 커널을 다운받아 부팅이 진행될 수도 있다. 특히 부트 롬이나 저장장치의 용량이 제한적일 경우는 커널 이미지 자체를 압축해 저장되는 것이 일반적이다.

임베디드 응용 프로그램
임베디드 응용 프로그램은 앞에서 구현된 커널과 파일 시스템을 바탕으로 수행된다. 응용 프로그램의 개발은 커널과 마찬가지 방법으로 호스트에서 생성이 가능하며 호스트에 설치된 개발 툴의 크로스 컴파일러에 의해 타겟 보드에 맞는 바이너리가 생성되게 된다. 생성된 응용 프로그램의 실행은 임베디드 OS 개발 툴 내의 타겟 에뮬레이터나 실제로 타겟 보드에 옮겨서 실행이 가능하다. 또한 응용 프로그램은 네트워크를 이용한 원거리 디버깅을 이용하거나, JTAG 인터페이스를 이용한 디버깅을 통하여 에러를 확인해 볼 수 있다.

임베디드 OS의 주요 개념 및 테크&팁
임베디드 시스템의 성능이 커지면서 기존에 간단한 펌웨어 형식으로 구현되었던 임베디드 프로그램이 점차 해야 할 일이 많아지고 복잡하게 된다. 이는 순차적인 프로그램으로는 해결하기 어려운 단계로 발전하고 결국 임베디드 시스템에도 운영체제의 개념이 필요하게 된다. 임베디드 시스템의 대부분 특성상 실시간이라는 요소를 만족해야 하는 점 때문에 많은 임베디드 OS는 RTOS의 속성을 가진다. 다음에 설명하는 주요 개념들은 여러분이 임베디드 OS를 이용해 임베디드 시스템을 개발하기 위하여 반드시 알아두어야 할 여러 개념 중 중요한 개념들을 선정하여 설명한 것이다.

스케쥴러
임베디드 OS는 보통 태스크(Task)라 불리는 프로그램 수행 단위를 가지게 된다. 보통 임베디드 시스템에서는 복수 개의 태스크가 동시에 수행되는 환경을 가지게 되며 이때 OS 내부의 스케쥴러에 의해서 다음 번에 수행되어야 할 태스크를 선택하게 된다. 이때 사용되는 임베디드 OS의 스케쥴링 알고리즘으로는 다양한 알고리즘이 나와 있지만 구현상의 문제 등으로 인해 실제 대부분의 임베디드 OS에서는 우선순위에 기반을 둔 스케쥴링 알고리즘을 사용한다.
대표적인 우선순위 알고리즘으로 FIFO(First In First Out)와 라운드로빈 방식이 있다. FIFO의 알고리즘은 동일한 우선순위를 가진 태스크들이 존재시 먼저 시작한 태스크가 종료될 때까지 다음 번 수행된 태스크가 스케쥴링을 받지 못하는 스케쥴링 알고리즘이며, 라운드로빈 방식은 동일한 우선순위를 가진 태스크들이 존재할 경우 각각 미리 정해진 타임슬라이스(time-slice)만큼씩 차례로 스케쥴링이 되는 알고리즘이다.

프리엠티브 커널
프리엠티브 커널(Preemptive kernel)은 어떤 태스크가 수행되고 있을 경우 커널이 강제로 그 태스크의 수행을 중지시키고 다른 태스크의 기능을 수행시킬 수 있는 능력을 지닌 커널을 말한다. Non-pree mptive 커널에 비해 interrupt latency가 조금 길어지는 단점이 있긴 하지만 대부분의 임베디드 OS에서 프리엠티브 커널을 채택하는 이유는 우선순위가 높은 태스크가 먼저 수행될 수 있다는 점 때문이다. 이는 결국 커널의 안정성을 높게 유지시킨다는 점에서 좋은 점이 될 수 있다.

상호 배제
하나의 태스크가 한 자원을 점유하여 사용중에 또다른 태스크가 접근하여 사용중인 자원에 무단으로 접근 시도 변경을 가한다면 곧 그 자원은 예측불허의 상황으로 치달을 수밖에 없다. 이런 부분을 임계 지역(critical section)이라 명하며, 한 자원이 점유중일 경우 나머지 자원들은 점유하고 있던 태스크가 자원을 모두 사용하고 사용권을 반환하기 전까지 모두 접근이 지연돼야 하는 지역을 말한다. 따라서 임계 지역은 상호 배제(mutual exclusion)로써 보호해야 하며 임베디드 OS는 상호 배제를 위해 인터럽트 Enable/Disable이나 세마포어의 기능으로 임계 지역을 보호할 수 있다.

태스크 커뮤니케이션
임베디드 OS에서의 태스크들은 종종 서로 데이터를 교환해야 할 경우가 생기게 된다. 이럴 경우 태스크간 통신을 통하여 교환할 수 있으며 이 기능은 OS에서 지원하는 여러 도구들에 의해 수행이 된다. 대표적인 방법으로는 시스템 전역의 변수를 선언하여 사용방법이 있으나 이 경우에는 변수 자체가 임계 지역이 되므로 인터럽트 Enable/ Disable이나 세마포어 등으로 상호 배제를 해야 한다. 그 밖의 방법으로는 큐, 파이프, 메일박스, 공유 메모리 등이 있으며 이들은 커널에 의해 자동으로 상호 배제가 이루어짐으로 임계 지역이 보호된다.


[ 임베디드 환경의 파일 시스템 ]
파일 시스템이란 저장장치에 파일을 관리하는 시스템을 말한다. 임베디드 시스템에서 주로 사용하는 저장장치는 보통 네트워크를 통한 외부 서버의 저장장치, 타겟 내의 일반 메모리 및 플래시 메모리 등을 말하며 각각 장치의 특성상 다른 파일 시스템이 올라가게 된다. 외부 서버로부터는 저장 장치에 대한 파일 시스템으로는 NFS(Network File System)라는 것이 있는데, 이는 네트워크를 통해 마치 외부 서버의 파일 시스템을 로컬의 파일 시스템처럼 사용할 수 있게 해주는 파일 시스템이다.
일반 메모리에 대한 파일 시스템은 RAMFS(RAm File System)이라 하여 보통 부트 롬 내에 파일 시스템 이미지를 저장해두고 시스템이 부팅시 일반 메모리에 그 파일들을 모두 복사한 다음 RAMFS를 통하여 파일을 유지 관리하는 파일 시스템이다. 단 일반 메모리에 구현돼 있으므로 타겟의 전원이 없어지면 그 내용이 소실된다.
플래시 메모리는 일반 메모리와는 다르게 전원이 나가도 그 내용이 보전되는 특성이 있으므로 한번 파일 시스템이 구현되면 그 내용이 보존되는 특징이 있다. 하지만 플래시 메모리의 특성상 기록 및 삭제의 횟수 제한이 있으므로 파일 시스템 내에서 이를 효율적으로 관리해 주는 부분이 고려되어야 한다.

[ 세마포어 ]
세마포어(semaphore)는 60년대 중반 Dijkstra가 고안한 메커니즘이다. 이는 태스크간에 상호 공유하는 변수이며, 임계 지역을 세마포어로 보호하면 태스크간 상호 배제을 구현할 수 있다. 기본적인 알고리즘은 먼저 세마포어 변수를 선언한 후 임계 지역에 전에 세마포어를 얻기를 시도한다. 만일 아무도 세마포어 얻기를 시도하지 않았으면 바로 임계 지역에 들어갈 수 있으나 다른 태스크가 세마포어를 얻어서 임계 지역에 있으면 나중에 시도한 태스크는 세마포어를 풀어줄 때까지 블럭 상태로 되게 된다. 이후 세마포어가 풀리면 블럭된 태스크는 세마포어를 얻어 임계 지역에 진입할 수 있게 된다.
세마포어는 초기화시 동시에 진입할 수 있는 개수를 명시할 수 있는데 그 개수가 하나인 세마포어에 대하여 바이너리 세마포어(binary semaphore)라 하며 그 이상의 값을 명시하면 카운팅 세마포어(counting semaphore)라 한다.

[ JTAG란? ]
JTAG(Joint Test Access Group)는 IEEE 표준 1149.1-1990 Test Access Port and Boundary-Scan Architecture에 근거한 규격으로 CPU에서 직접 지원하는 디버깅을 위한 인터페이스로 현재 CPU의 상태를 점검하거나 프로그램의 디버깅, 플래시 메모리에 새로운 자료를 저장할 때 주로 사용한다.

Priority Inversion
낮은 우선순위를 가진 태스크에 의해 높은 우선순위를 가진 태스크가 블럭되어 수행이 되지 않는 현상을 말한다. 이러한 우선 순위 역전 현상은 시스템의 schedulability와 predictability를 떨어뜨려 결국 시스템을 불안정하게 만드는 원인이 되기도 한다. 일부 임베디드 OS에서는 OS 차원에서 priority inheritance를 이용하여 해결하기도 하나, 가장 안전한 방법은 태스크들을 디자인할 경우 그러한 상황이 벌어지지 않도록 설계를 하는 것이다. 보통 이를 막기 위해 같은 세마포어를 쓰는 태스크들 사이에는 같은 우선순위를 주는 등의 방법을 사용한다.

Priority Inheritance
우선 순위 역전현상을 피하는 방법으로 예를 들면 태스크 T2가 특정 리소스를 점유하고 있는 상태에서 우선순위가 높은 T1이 같은 리소스에 접근할 경우 우선순위 역전현상이 나타난다. 이때 이 리소스를 대기하고 있는 가장 큰 우선순위인 T2의 우선순위만큼 T1이 우선순위를 상속(inheritance)받아서 그 우선순위의 값을 유지한 상태로 리소스를 점유하게 된다. 이후 해당 리소스를 모두 사용한 후에는 다시 원래의 T1의 우선순위 값으로 환원된다.

'Computer Science' 카테고리의 다른 글

WebOS  (0) 2009.08.30
MS Windows에서 DevC++로 GTK프로그래밍하기  (0) 2009.08.17
[summary] linux device driver  (0) 2009.08.12
Getting started with an embedded Linux system emulator  (0) 2009.08.09
[컬럼] 초보자를 위한 임베디드 리눅스 학습 가이드  (0) 2009.08.02

[summary] linux device driver


디바이스드라이버의 역할은?
- 응용프로그램이 H/W를 제어할 수 있도록 Interface를 제공해 주는 것이다.
- 시스템이 지원하는 하드웨어를 응용프로그램에서 사용할 수 있도록 커널에서 제공하는 라이브러리다.
- 디바이스와 시스템메모리 간에 데이터의 전달을 담당하는 커널 내부 기능이다.
- 디바이스를 제어하는 함수 집합

디바이스드라이버의 인터페이스
- 일반적으로 위로는 파일시스템(file system)과 아래로는 실제 디바이스와 인터페이스를 갖는다.

응용프로그램이 커널에게 자원 처리를 요청하는 두 가지 방법
- System call (S/W ISR)
- File I/O (Device Driver)

커널소스탐색
- http://lxr.linux.no/linux/

grep 명령의 활용
ex) grep readb * -r | grep include

이외에 include/linux, include/asm 활용. 한편, SourceInsight 는 코드 분석을 위해 유용하다.

module programming의 장점
부팅 중에도 디바이스드라이버를 수정할 수 있다.

리눅스에서 동작하는 프로그램은 H/W를 제어하기 위해 디바이스 파일을 이용해야만 한다.
디바이스 파일은 mknod로 생성한다. 이 파일에 대한 I/O는 저수준 함수를 사용한다.
open, close, read, write, ioctl, fsync, lseek
int fd = open("/dev/mem", O_RDWR | O_NONBLOCK); ....

문자 디바이스 드라이버(버퍼없는 디바이스드라이버)
- ex) 터미널 드라이버
http://lxr.linux.no/linux/drivers/char/tty_io.c
http://lxr.linux.no/linux/drivers/char/serial167.c


통합형 디바이스 드라이버란?
- ?

하나의 디바이스는 여러 개의 드라이버에 의해 동작할 수 있다.

Bus는 직/간접적으로 프로세서에 연결되고, 디바이스는 하나의 버스에 연결된다.

디바이스파일의 목적
- H/W 를 다루는 드라이버의 정보를 커널에 제공하는 데 있다.
- 응용프로그램은 시스템에 의해 할당된 메모리와 파일만 제어할 수 있고, H/W에 직접 접근할 수는 없다. 그래서, 디바이스파일이라는 특수 파일을 이용한다.
- 디바이스파일은 H/W를 제어하는 디바이스드라이버와 연결된다.

주번호와 부번호
- 주번호가 같다는 것은 같은 드라이버에 의해서 구동될 수 있다는 의미가 된다.

(문자)디바이스드라이버 구현 순서
1. 디바이스드라이버 함수 구현
2. 디바이스드라이버 커널 등록 (register_chrdev()) http://lxr.linux.no/linux/fs/char_dev.c#L266
3. 디바이스 파일 생성 (mknod)

문자디바이스드라이버 sample
- http://halkamalka.tistory.com/29

디바이스드라이버 read/write 구현 시 알아야 할 사항
1. User memory space와 Kernel memory space 사이에 데이터 이동
read 의 인자는 드라이버의 xxx_read의 인자로 연결되지만, User application에서 전달된 인자의 buffer에 드라이버에서 직접 접근할 수는 없다. 왜냐하면, 메모리 공간이 각각 Kernel과 User로 서로 다르기 때문이다. 따라서, 이렇게 다른 영역에 데이터를 전송하기 위해서는 다음의 함수를 사용한다.
- copy_to_user(to, from, n); // Kernel에서 User로 n만큼
- put_user(x, ptr) // 커널의 x값을 사용자 메모리(ptr) 값에 대입한다.
- H/W에서 직접 읽기: inb, outb, readb, writeb etc
cf) copy_from_user(to, from, n) , get_user(x, ptr)
위 함수들을 사용하기 위해서는 다음 header를 포함시켜야 한다.
#include <asm/uaccess.h>

verify_area example

ssize_t xxx_read(struct file* file, const char* buffer, size_t count, loff_t* f_pos)
{
int err;
err = verify_area(VERIFY_WRITE, (void*) arg, size);
if(err < 0)
return err;
return 0;
}


copy_to_user example

ssize_t xxx_write(struct file* file, const char* buffer, size_t count, loff_t* f_pos)
{
char* temp;
int err;
temp = kmalloc(count, GFP_KERNEL);
if(err = copy_to_user(temp, buf, count) < 0)
return err;
kfree(temp);
}

copy_from_user example

ssize_t xxx_read(struct file* file, const char* buffer, size_t count, loff_t* f_pos)
{
char* temp;
int err;
temp = kmalloc(count, GFP_KERNEL);
if(err = copy_from_user(temp, buf, count) < 0)
return err;
kfree(temp);
}

2. 처리 조건이 되지 않았을 때의 blocking처리
3. H/W 제어 함수
4. 여러 프로세스가 동시에 접근했을 때의 경쟁 처리
5. ISR와의 경쟁 처리

전역 변수 할당 시 참고 기준
1. H/W 관련 제어 변수는 전역 변수로 만든다.
2. 단독으로 사용되는 ISR에서 사용되는 변수들은 전역 변수로 만든다.
3. 프로세스마다 따로 관리해야 하는 변수(REENTRANT를 고려해야 하는) 들은 file구조체의 private_date필드 변수에 할당한다.
4. H/W와 연동하는 대기 큐는 전역 변수로 만든다.

I/O처리
H/W는 프로세서 입장에서 I/O 주소 영역으로 표현되는 메모리 공간이다. 이 메모리 공간을 제어하는 방법은 시스템마다 다르므로 이를 통일하기 위해 몇 가지 함수를 정의한다.
1. I/O mapped 입출력 함수
inb, inw, inl, insb, insw, insl : H/W에서 데이터를 읽는다.
outb, outw, outl, outsb, outsw, outsl : H/W에 데이터를 쓴다.
* 위 함수들은 MACRO이며, #include <asm/io.h>에 정의되어 있다.
* arch 마다 다르게 구현되어 있으므로, 참고할 필요가 있다.
2. Memory mapped I/O 함수
PCI 디바이스나 ARM같은 프로세서는 H/W가 I/O port에 연결되어 있지 않고 메모리 공간에 연결된다.
readb, readw, readl, memcpy_fromio
writeb, writew, writel, memcpy_toio


'Computer Science' 카테고리의 다른 글

MS Windows에서 DevC++로 GTK프로그래밍하기  (0) 2009.08.17
임베디드 OS란 무엇인가  (0) 2009.08.15
Getting started with an embedded Linux system emulator  (0) 2009.08.09
[컬럼] 초보자를 위한 임베디드 리눅스 학습 가이드  (0) 2009.08.02
리눅스 디바이스 드라이버 개요 및 실습  (0) 2009.08.02
Getting started with an embedded Linux system emulator
ByLinux Devices
2008-12-22


Foreword -- This article describes setting up an embedded Linux cross-development environment targeting a virtual machine running on the development host. It covers installing Qemu and using it to debug applications and kernels, both with supplied test-images and with custom kernel/filesystem images...

created with Buildroot.

The article was written by Gilad Ben-Yossef, co-founder of Israel-based embedded Linux training and consulting firm Codefidence. Ben-Yossef originally published the article on his Tuxology blog. Enjoy . . . !

Building an embedded Linux system emulator
by Gilad Ben-Yossef


One of the hallmarks of embedded system programming is working with specialized hardware. Unfortunately, embedded system developers do not always have the luxury to develop and test their code on the actual hardware they target. Often, the hardware is developed in tandem with the system software and therefore it it is not available for much of the embedded system software development cycle.

While one can develop and test much of our code on a PC running Linux, such a PC is a very different environment from the target board. More often then not, the target board is not even of the same architecture as the PC. A solution to this problem can be obtained by using an emulator - a software tool that executes software code of our target platform in a virtual machine that is running on our development host, and running our system software in it.

The following article describes how to build an embedded Linux system running inside an emulator which can be used to develop, test and debug target code even without access to target hardware.


The components

To build our emulator we will need the following components:
  • Hardware emulator (we'll use Qemu)
  • Minimal Linux root file system containing a C library and Busybox
  • The Linux kernel

Installing Qemu

Created by Fabrice Ballard, Qemu is an open source machine emulator supporting seven target architectures, including x86, MIPS, ARM, and PowerPC. As first step, we will download and install the emulator. Depending on the Linux distribution you use on your workstation, you might be able to use the native package management system of the distribution to do so.

For Debian, Ubuntu and derivatives:

$ sudo apt-get install qemu

For Fedora and derivatives (as root):

# yum install qemu

For other distributions lacking a Qemu package, or for those wishing to obtain the very latest package (note that the "i386" label refers to the host running the emulator, and not the target platform):

$ wget http://bellard.org/qemu/qemu-0.9.1-i386.tar.gz
$ cd /
$ sudo tar zxvf qemu-0.9.1-i386.tar.gz

Or, as root:

# tar zxvf qemu-0.9.1-i386.tar.gz

Alternatively, you can download the sources and build the emulator from scratch. This has the added advantage that you can later adapt the emulator to more accurately reflect your actual hardware:

$ wget http://bellard.org/qemu/qemu-0.9.1.tar.gz
$ tar zxvf qemu-0.9.1.tar.gz
$ cd qemu-0.9.1/
$ ./configure
$ make
$ sudo make install

Or, as root:

# make install


Kernel and file system images

The Qemu emulator we have just installed provides a virtual machine mimicking our target hardware. To actually get Linux running on this virtual machine, however, we will need to download an image of the Linux kernel and a suitable root file system image for our target architecture.

Luckily, the Qemu project provides test images for several architectures that can be used to get a fast start with Qemu as an embedded Linux system emulator. Go to the Qemu project download page and choose one of the Qemu test disk images suitable for your embedded platform and download it to your Linux host (in this example we use ARM):

$ wget http://bellard.org/qemu/arm-test-0.2.tar.gz

Now extract the image:

$ tar zxvf arm-test-0.2.tar.gz
$ cd arm-test


Booting Linux on the emulator

Start up Qemu with the following command line, adjusting the architecture name, kernel file name, and root file system image name according to your specific architecture (again, we use ARM in this example):

$ qemu-system-arm -kernel zImage.integrator \
   -initrd arm_root.img -tftp / -redir tcp:9999::9999

The above command line starts Qemu in system emulation mode, booting into the kernel image zImage.integrator while loading into the virtual machine RAM the arm_root.img file system, and instructing Qemu to make your entire host root file system available for access via TFTP from the emulated machine (more on this ahead).

You should now be seeing a window similar to the following in which the emulated LCD display of the board is shown:


Qemu screenshot
(Click to enlarge)


You can log-in with the user "root" -- no password is required.


Transferring files to and from the host

The emulator and file system are set up to automatically configure a virtual Ethernet interface in the virtual machine with an internal IP. Through that virtual network interface, the emulator is set up to enable transferring of files to and from the host machine file system using the TFTP protocol.

For example, the following command will copy the file "/home/gby/hello_emu" from the host file system to the current directory inside the emulator:

$ tftp -g -r /home/gby/hello_emu -l hello_emu 10.0.2.2

The following command will copy the file "/root/test.log" from the emulator to the host file system directory "/home/gby/":

$ tftp -p -l/root/test.log -r /home/gby/test.log 10.0.2.2

In addition, you can use the "wget" comment to transfer files using the FTP and HTTP protocol to the emulator from any compatible server accessible in the network:

$ wget http://codefidence.com/some/file

Qemu supports numerous other way to interact with the host and it's environment, including bridged virtual network interfaces (as opposed to the default NAT used in the example above). Bridged virtual network interfaces enable:
  • Using NFS to communicate with the host
  • Remote debugging from the host
  • VLAN support
  • Exposing the host file system as a FAT file system
  • Mounting disk, flash, or CDROM images from the host file system
  • Using USB devices connected to the host
For more information on these advanced options, please refer to the Qemu user manual.


Debugging user applications

Using the GNU debugger GDBserver agent, we can debug applications running inside the emulator using the GDB debugger on the host. To do this, first use one of the methods outlined above to copy the "gdbserver" executable to the emulator. Note that you will need a gdbserver executable that was built to run on the target architecture (such as ARM, in the example above), and not on that of the host!

Also note that since the test images do not contain debugging symbols for the system libraries, you will only be able to debug statically compiled applications using them. This limitation can be removed by building your own kernel and file system image (see below for more information on this topic).

$ tftp -g -r /home/gby/src/gdb/gdb/gdbserver/gdberver \
   -l gdbserver 10.0.2.2

Next, assign the gdbserver binary execute permissions:

$ chmod u+x gdbserver

Now, run the gdbserver agent, instructing it to use port 9999 (which we previously redirected to the emulator, when we launched qemu-system-arm from the command-line) to listen for connections from the debugger:

$ gdbserver 0.0.0.0:9999 /bin/myprog

Or, if you wish to attach to an already running program, use:

$ gdbserver 0.0.0.0:9999 --attach 1234

Finally, run the GDB debugger on your host and instruct it to connect to the host local port 9999:

$ arm-linux-gdb target/bin/myprog
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
...
(gdb) set solib-absulote-prefix /dev/null
(gdb) set solib-search-path target/lib/
(gdb) target remote 127.0.0.1:9999


Debugging the kernel

Using the Qemu emulator to debug kernel code is quite straight forward, as Qemu incorporates a minimal GDB agent as part of the emulator itself. To debug the Linux kernel running inside the emulator, add the "-s" parameter to the command line used to start Qemu:

$ qemu-system-arm -kernel zImage.integrator \
    -initrd arm_root.img -tftp / -redir tcp:9999::9999 -s

Now when the emulator starts, it will wait for a debugger connection on the default port "1234" (or a different port specific with the "-p" option), before proceeding with the boot. Once the emulator has started, you can debug the Linux kernel running inside it, using GDB on the host:

$ arm-linux-gdb linux/vmlinux
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
...
(gdb) target remote 127.0.0.1:1234

You can use GDB as you normally would. For example, type "cont" to launch the kernel:

(gdb) cont


Building your own kernel and file system images

So far we have seen how to use the Qemu emulator with the test kernel and file system images that are available on the Qemu site. To make full use of the emulator, we can create our own custom kernel and file system images that will better reflect the real target we are trying to develop for.

First, query Qemu regarding which boards it can emulate for your chosen architecture. Replace "arm" in the example above with one of: mips, x86_64, ppc, or sparc. For i386, simply use "qemu" as the command:

$ qemu-system-arm -M \?

Choose the board that most closely resembles your real target environment. Note that you can add support to Qemu of your specific true board. This requires some programming though, and we shall not cover it in this tutorial.

The creation of a kernel and file system for our emulated target is no different then doing the same task for real hardware. In fact, many tools are freely available to accomplish this task. In this example, we shall use the Buildroot framework. Buildroot is a set of make files and patches that simplify the generation of a cross-compilation tool chain and root file system for your target Linux system, using the uClibc C library.

First, we shall download the latest Buildroot release from the project web site and extract it:

$ wget http://buildroot.uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2
$ tar jxvf buildroot-snapshot.tar.bz2
$ cd buildroot/

Next, let's configure Buildroot for our chosen target board:

$ make menuconfig

You will be presented with a menu enabling you to pick your architecture, sub-architecture, specific board to build for. Other options include GCC and uClibc versions, and related details. For each menu choice in the configuration tool, you can find associated help information describing the purpose of the entry.

At minimum, the following configuration options needs to be set:
  • Target Architecture option -- choose your target architecture (e.g., arm.)
  • Target Architecture Variant option -- Chose a specific model of the architecture (e.g., arm926t).
  • Target options menu -- If the target board you wish to emulate (that is supported by Qemu) is listed, turn on support for that board (e.g., enable the "ARM Ltd. Device Support" menu, and inside it choose the "Integrator arm926" option).
  • Toolchain menu -- Turn on "Build gdb server for the Target" option, and if you would like to test C++ programs on the emulator, also the "C++ cross-compiler support" option.
  • Target filesystem options menu -- Enable the "cpio the root filesystem" option, and choose the "gzip" compression method. You may also request the file system image to be copied to a specified directory once it is generated.
  • Kernel menu -- Choose the "linux (Advanced configuration)" option, and pick one of the offered Linux kernel versions of the list offered. Also, select the "zImage" binary format. Here, you can also specify a directory to copy the generated kernel to.

    In addition, you will need to supply a proper Linux kernel configuration file. Note that you can extract the kernel configuration file used to generate the kernel supplied as part of the test images, by issuing the following command from inside the emulator:

    $ zcat /proc/config.gz > linux.config

    Alternatively, Linux provides specific kernel configuration for optimal use with Qemu for some architectures. Run the following command to inspect the default kernel configuration included in a specific Linux kernel version:

    $ make help
When you're done configuring Buildroot, exit the configuration utility (making sure to OK saving the changes) and type: "make". Buildroot will now download all required sources, and build your new kernel and file system image for you. You should now be able to run the emulator using the kernel and file system image you have just created. Use the file name and path of the zImage binary as a parameter to Qemu's "-kernel" option, and the file name and path of the file system image with Qemu's "-initrd" parameter, like so:

$ qemu-system-arm -kernel zImage \
    -initrd rootfs.arm.cpio.gz -tftp / -redir tcp:9999::9999 -s


As we have shown, the Qemu emulator provides a fairly simple way to develop, debug, and test Linux kernels, drivers, and applications for a variety of embedded architectures, even when no actual hardware is available. More information about the software used in this article can be found on the qemu, gdb, and Buildroot websites.


About the author -- Gilad Ben-Yossef is the co-founder and CTO of Codefidence Ltd, and has been helping OEMs make and use free and open source software in commercial products and services since 1998. He is also the co-author of the book "Building Embedded Linux Systems," 2nd Edition. In addition, he is co-founder of Hamakor, an NPO devoted to the promotion of FOSS in Israel, as well as a founding organizer of "August Penguin," an Israeli community FOSS conference.

Gilad is a member of the Israeli chapter of Mensa, the Israeli Information Technology Association and the Israeli chapter of the Internet Society. He holds a B.A. in Computer Science from Tel-Aviv Jaffa Academic College. When not trying to make FOSS software do something the authors never intended, Gilad likes to SCUBA dive, read science fiction, and spend time with his wife Limor and his and two adorable girls, Almog and Yael.



'Computer Science' 카테고리의 다른 글

임베디드 OS란 무엇인가  (0) 2009.08.15
[summary] linux device driver  (0) 2009.08.12
[컬럼] 초보자를 위한 임베디드 리눅스 학습 가이드  (0) 2009.08.02
리눅스 디바이스 드라이버 개요 및 실습  (0) 2009.08.02
엔터프라이즈, 아키텍쳐, 디자인패턴, 프레임워크  (0) 2009.07.18

[컬럼] 초보자를 위한 임베디드 리눅스 학습 가이드

  목차   1.    개요   2.    저작권   3.    문서   4.    임베디드 리눅스를 공부하기 위하여 자신의 상태에 따라서 무엇을 해야 하는가?   4.1   임베디드리눅스를 공부하고자 하는분들이 가장 먼저 해야 할일   4.2   리눅스를 설치 해 본적도 없는 초 울트라 초차   4.3   리눅스 명령에 익숙하지 않다면   4.4   리눅스 디렉토리 구조를 모른다면   4.5   쉘 스크립트를 모른다면   4.6   유닉스 운영 체제를 모른다면    4.7   C 언어를 모른다면   4.8   리눅스에서 도는 어플리케이션을 작성한 적이 없다.    4.9   make 사용법을 모른다면   4.10  리눅스가 동작하기 위한 최소한의 기본 구성에 대해 아는 것이 없다.    4.11  커널 컴파일을 해 본적이 없다면.   4.12  커널의 구조를 모른다면   4.13  어셈블러를 모른다면   5.    윗글에서 제안한 리눅스의 개발과 관련한 기본을 다진후 진행하는 방법    5.1   디바이스 드라이버를 정복하라!!!   5.1.1 어떤 책이 좋을까?   5.1.2 디바이스 드라이버 프로그램을 직접 해본다.    5.1.3 프린터 포트를 이용한 캐랙터 디바이스를 만든다.    5.1.4 자신이 사용하는 커널 버전이외의 내용은 과감하게 삭제한다.    5.1.4 네트웍크용 디바이스 드라이버는 공부해라.   5.1.5 기존에 디바이스 드라이버를 한번쯤 스스로 재 작성해 보라.   5.2   커널을 이해하라....   5.3   커널을 이해하기 위한 방법론 및 어디까지?   6.    정말 임베디드 리눅스를 하려면    6.1   평가 보드를 구매하라...   6.2   평가 보드를 구매 했다면....   6.3   MCU를 공부하라..   6.4   평가 보드의 회로를 공부해라...   6.5   평가 보드에 사용되는 디바이스를 공부해라...   6.6   크로스 컴파일 환경을 구축하는 것을 공부하라...   6.7   부트 로더를 공부하라.   6.8   NFS 시스템에 대해서 공부하라...   6.9   그외 나머지는 어떻게?   6.9.1 MMU가 없다..   6.9.2 루트 디스크 이미지와 램 디스크    6.9.3 플래쉬 메모리에 대해서 공부 할것   6.9.4 계속 늘어 놓으면 한도 끝도 없을 것 같으므로 ...   7.    빨리 개발하는 방법....   7.1   이미 개발된 평가 보드를 이용할 것...   8.0   내가 하고 싶은 말은 ...

1. 개요

이 문서의 내용은 정말 초보자가 임베디드 리눅스를 어떻게 접근하면 좋은가에 대한 생각을 적어 놓은 것이다.


2. 저작권

이 문서는 GNU 라이센스를 따른다.
단 최초 작성인은 유영창임을 표시하여야 한다.

3. 문서

버전 1.0 - 2001. 06. 11
버전 1.1 - 2001. 06. (html version)

이 문서에 불만이 있거나 다른 생각이 있다면 여기로 메일을 보내 줄것

frog6502@hanmail.net


4. 임베디드 리눅스를 공부하기 위하여 자신의 상태에 따라서 무엇을 해야 하는가?

4.1 임베디드리눅스를 공부하고자 하는분들이 가장 먼저 해야 할일
임베디드 리눅스를 해야 겠다는 생각만 가지고 있다가 이젠 시작해야지 라는 생각을 하셨다면 우선 숨을 크게 들이키시고 내벹는 행동을 반복하신후 임베디드 리눅스를 단번에 점령하겠다는 생각을 버린다. ^^; 정말 임베디드 리눅스는 한번 들어가 보면 끝이 없어서 한두달 만에 끝장을 보겠다는 생각을 가지셨다면 당장 그만 둘것! 당장 그만 두지 않더라도 조만간 그만 두게 될것이다. 왜? 한두달안에는 끝나지 않기 때문이다. 혹시 시작하는 시점의 여러분의 실력이 리눅스의 커널을 이미 분석이 끝난 실력이라면... 더구나 여러 아키텍쳐에 포팅까지 한 실력이라면 정말 한두달 사이에 끝날수 있을 것이다. 굳이 임베디드 리눅스를 따로 할 필요가 없는 실력자이므로...
4.2 리눅스를 설치 해 본적도 없는 초 울트라 초차
당장 리눅스 배포판을 구한다. PC에 리눅스를 설치한다.
4.3 리눅스 명령에 익숙하지 않다면
우선 리눅스에 관련된 책을 한권 산다. 그리고 한번 쭈욱 읽어 본다. kldp.org 싸이트에 들락 날락 거리면서 man.kldp.org 도 참고 하면서.... 단 주의 할것은 암기력에 자신 있는 분을 제외하고는 명령을 굳이 외우려고 하지 말것 자주 사용하는 명령은 손가락이 외운다. 굳이 사용도 하지 않는 명령을 외우려고 스트레스 쌓이지 말고... 더구나 리눅스 명령어는 정말 정말 너무 많다.
4.4 리눅스 디렉토리 구조를 모른다면
최상위 디렉토리를 외운다. 몇 개 안되므로... 그리고 서점에 간다... 리눅스 관련 책들을 보면서 디렉토리에 관련된 내용을 중점적으로 읽는다. 읽어야 하는 내용은 디렉토리 구현에 대한 것이 아니라.. 각 디렉토리를 어떻게 구분해 놓았는가를 설명한 내용들을 읽는다. 대부분의 책들이 조금씩 만 소개하므로 굳이 책들을 사려고 하지 말 고 서점에서 여러권을 설렵하는 것이 났다. 그리고 이것저것 패케지들을 손수 설치해 본다. 그러면 저절로 깨닫게 될것이다.
4.5 쉘 스크립트를 모른다면
리눅스를 하면서 쉘 스크립트를 모르면 고생문이 훤하다 사실 내가 그렇다. 그러나 쉘 스크립트를 아주 잘 할 필요는 없다. 쉘 스크립트를 읽을 정도면 된다. 쉘 스크립트를 작성할 필요가 있다면 스크립트에 대한 강좌를 인터넷에서 보고 하거나 다른 스크립트를 보면서 하면 되니까....
4.6 유닉스 운영 체제를 모른다면
유닉스 운영체제에 대한 최대한 쉽게 설명한 책을 골라서 그냥 소설 읽는 셈 치고 읽어 본다. (참고) 쉽게 설명한 책들의 특징은
1. 그림이 많다.
2. 글씨가 크다.
3. 가격이 싸다.
4. 많은 사람들이 본다.
5. 두께가 얇다.
4.7 C 언어를 모른다면
이건 사람 얼굴에 입이 없는 셈이다. 밥 어떻게 먹으려나... 곧 굶어 죽게 될것이다. 바로 C의 기본적인 설명에 대한 책을 독파한다. 이건 정성 들여서 독파해야 한다. 임베디드 리눅스는 거의 C로 시작해서 C로 끝난다. 가끔 C++도 있지만....
4.8 리눅스에서 도는 어플리케이션을 작성한 적이 없다.
http://users.unitel.co.kr/~sangeun5/linux/lpg.html 에 가본다. 정말 도움이 될것이다
4.9 make 사용법을 모른다면
make 사용법을 아주 잘 알 필요는 없다 그러나 기본적인 사용법은 알고 있어야 한다. 아주 복잡한 사용법은 이미 기술된것을 이용하는 것으로 충분하다.
4.10 리눅스가 동작하기 위한 최소한의 기본 구성에 대해 아는 것이 없다.
부팅 디스크를 만들어 본다. 여기서 주의 할것! 대부분의 분들이 켈프에 있는 부팅 디스크 만들기를 따라만 하시는데 이건 별로 효과가 없다. 부팅 디스크를 만드는 목적은 리눅스가 동작하기 위한 최소한의 기본 구성을 알고자 하는데 목적이 있다. 또한 로더의 필요성 커널과 루트 이미지의 분리와 램디스크에서 동작하는 것에 대해서 또 커널이 동작한 후에 실행되는 최소한의 진행과정을 이해하기 위한 것이다. 이를 알고자 하는데 목적을 두어야지 만드는데에만 열중하면 안된다. 또한 다른 부팅 디스크 이미지를 이용하여 그 내용을 살표보고 공부하여야 한다.
4.11 커널 컴파일을 해 본적이 없다면.
임베디드 리눅스는 커널을 가지고 놀아야 한다. 물론 안하고 하는 방법은 있다. 그러나 대부분의 임베디드 리눅스에서 커널 컴파일과 환경 설정은 거의 필수이다. 임베디드상에서 리눅스의 커널 환경을 설정하고 컴파일하는 방식과 우리가 일반적으로 다루는 PC의 커널을 다루는 방법은 거의 대부분이 같다. PC상에서 커널을 자유자재로 가지고 논다는 것은 "임베디드상에서도 자유롭다"는 것을 의미한다.
4.12 커널의 구조를 모른다면
Uinx kernel 완전분석으로 가는길이라는 책을 한번 볼것
약간은 예전의 커널에 대한 이야기가 나오지만 커널이 어떻게 동작하는 지를 알수 있다.
4.13 어셈블러를 모른다면
임베디드 리눅스를 함에 있어서 어셈블러를 몰라도 가능한 영역은 있다. 그러나 많은 부분에서 부딪히게 된다. 고로 어셈블러는 필요 충분 조건이다. 어셈블러라는 것이 너무도 많은 종류가 존재하므로 모두 다 익히기는 어렵지만 자신이 사용하려는 MCU의 어셈블러는 익혀야 한다. 일단 PC를 이용한 임베디드에 대해서 익히려면 PC의 어셈블러는 알아야 한다. 자유 자재로 구사할 정도로 익힐 필요는 없다. 다른 쏘스의 명령을 이해하고 자신이 필요로 하는 기능을 추가하거나 수정 할수 있을 정도면 된다.

5. 윗글에서 제안한 리눅스의 개발과 관련한 기본을 다진후 진행하는 방법

임베디드 리눅스를 할때 많은 분들이 평가 보드를 이용한 학습을 준비한다. 그러나 이런 분들은 대부분 좌절한다. 왜? 기본기가 없는 분들이 평가 보드에 포팅하겠다고 덤비기 때문에 좌절하는 것이다. 포팅이 그리 쉬운 것은 아니다. 일단 PC에서 내공을 쌓은 후 접근하는 것이 수월하다. 임베디드 리눅스라고 PC의 리눅스와 다른 점은 거의 없다. 단지 아키텍쳐만이 다를 뿐이며 이 부분은 전체에 3%도 되지 않는다. PC에서 리눅스의 내부를 자유 자재로 드나드는 분이면 임베디드 리눅스에 접근은 너무도 쉽다. 사실 몇가지 사항을 제외하고는 임베디드 리눅스보다 PC 시스템이 더 복잡하다. 가격도 비교해보면 임베디드 장비가 더 싸다.. ^^; 자 이젠 PC에서 임베디드 리눅스를 하기 위한 접근 방법을 알아 보자. 그리고 공부하기 위하여 평가 보드를 구입하기에는 개인이 구입하는 가격이 너무 고가이다. 컴퓨터를 또하나 사는 셈인데...이게 말처럼 쉽겠는가? 고액 연봉자라면 모를까....
5.1 디바이스 드라이버를 정복하라!!!
임베디드 시스템을 개발하는 과정에서 하드웨어쪽을 제외한 나머지 소프트웨어 측면에서 개발 비중은 로더 및 하드웨어 테스트 프로그램 10% 커널 포팅 10% 디바이스 드라이버 40% 임베디드 어플리케이션 40% 이렇다. 물론 내 개인적인 생각이므로 상황에 따라 다르겠지만 .... 그만큼 디바이스 드라이버는 중요하다. 디바이스 드라이버를 개발 한다고 평가보드를 구매 해야 하는가? 이에 대답은 "아니오" 이다. PC는 매우 복잡한 시스템이다. 임베디드에 사용되는 대부분의 기능이 PC에는 있다. 그러므로 PC에 도는 하드웨어에 관련된 디바이스 드라이버를 스스로 만들 능력이 된다면 임베디드용 디바이스 드라이버를 만들 능력은 충분해 진다. 일단 돈 안드는 PC부터 정복해라. PC가 없다면 모를까 ^^; 자 그럼 디바이스 드라이버는 어떻게 정복하는 것이 좋을까? 한번 알아보자..
5.1.1 어떤 책이 좋을까?
디바이스 드라이버를 만드는 방법에 대한 책으로 대표적인것에는 오렐리의 책이 있다. 그러나 이책을 초보자가 보기에는 너무 어렵다. 그렇다고 마땅한 다른 책이 있는 것도 아니다. 고로 선택권이 없으므로 이 책을 여러번 읽어 본다. 완벽하게 이해하려고는 하지 말기를 부탁한다. 여러번 읽어 보면 어렴풋이 무슨 내용인지 이해하는 시점이 있을 것이다.
5.1.2 디바이스 드라이버 프로그램을 직접 해본다.
우선 오렐리의 책에 소개된 싸이트에 가서 쏘스를 가져 온다. 그리고 쏘스를 이해하려고 노력한다. 또한 KELP의 내가 쓰고 있는 디바이스 드라이버의 강좌를 계속 지켜 보거나 현재 진행되고 있는 박철님이 진행하고 있는 목요 세미나에 참가한다. 아니면 웹을 뒤지면 의외로 디바이스 드라이버 강좌를 하는 싸이트가 꽤 된다. 싸이트 이름을 내가 일일이 외우기는 힘들지만 ... ^^; ( 천재는 건망증이 심하다고들 한다. )
5.1.3 프린터 포트를 이용한 캐랙터 디바이스를 만든다.
대부분의 임베디드 장비에서 사용되는 디바이스는 캐랙터 디바이스로 충분하다. 고로 캐랙터 디바이스를 안다는 것은 임베디드용 디바이스 드라이버의 절반에 해당하는 내용을 안다는 의미도 된다.
5.1.4 자신이 사용하는 커널 버전이외의 내용은 과감하게 삭제한다.
현재 임베디드용 커널은 2.2대를 근거로 사용한다. 2.4대는 최근에 나왔으므로 아직은 적용중이다. 임베디드용 커널은 버전이 낮다. 또 2.0 대 이전 버전은 약간 적용 방식이 다른 것으로 기억한다. 이를 위해서 오렐리 책에서는 이런 저런 내용을 기술하고 있는데 실전에 사용되는 임베디드 리눅스는 사실 커널을 여러가지로 사용하겠끔 굳이 설계하지 않아도 된다. 즉 커널 버전을 덜 타는 것이다. 범용적인 PC용 디바이스 드라이버를 작성할때나 고려할 내용이다. 그러므로 여러분은 괜히 쏘스를 어지럽히는 커널의 버전 관리 에 대한 내용은 과감하게 제거하고 진행하는 것이 수명 연장에 지름길이 된다.
5.1.4 네트웍크용 디바이스 드라이버는 공부해라.
임베디드 장비에 리눅스를 사용하는 가장 큰 목적 중에 하나가 네트워크 스택을 이용하기 위한 것이다. 리눅스 자체가 덩치가 크므로 조그마한 임베디드 장비에는 아예 탑재하지 않는다. 채산성이 전혀 맞지 않기 때문이다. 더구나 리눅스의 대부분의 어플리케이션이 네트워크에 연관되어 있다. 고로 네트워크 디바이스 드라이버는 공부해야 한다.
5.1.5 기존에 디바이스 드라이버를 한번쯤 스스로 재 작성해 보라.
계속 말하는 것이지만 PC는 매우 복잡한 시스템이다. 고로 PC의 디바이스 드라이버를 구현 할수 있다는 것은 임베디드용 디바이스 드라이버를 구현 할 수 있는 능력이 된다는 것과 동일한 내용이다. 여기서 주의 할것은 PC에서 구현된 디바이스 드라이버들은 매우 안정된 상태이다. 여러분이 이렇게 완벽하게 안정된 디바이스 드라이버를 만들 수는 없다. 왜? 초짜이므로.... 똑같이 안정된 디바이스 드라이버를 작성할수 있다면 바로 리눅스의 개발에 앞장 서 주시길 부탁한다. 보통 많은 분들이 PC용 디바이스 드라이버를 재 작성할때 시리얼 포트용 디바이스 드라이버 부터 하는데 제발 시리얼 포트 부터 하지 말것... PC의 리눅스 상에서 시리얼은 정말 복잡하다. 보통 임베디드의 시리얼과는 상대가 되지 않는다. 터미날을 지원하는 기능과 가상 터미날과 연계 되어 있기 때문이다. 고로 차라리 프린터 포트나 마우스 같은 디바이스 드라이버 부터 만들어 가라... 어쩌면 랜카드용 디바이스 드라이버가 더 쉬울지도 모른다. 다시 당부 드리지만 시리얼 포트 부터 접근하지 말것....
5.2 커널을 이해하라....
디바이스 드라이버를 공부하다보면 많은 부분들이 커널과 연계되어 있음을 알게 된다. 그러므로 디바이스 드라이버에 대해서 공부가 끝났다면 커널의 40%쯤은 이해 했다고 볼 수도 있겠다. 커널을 공부함에 있어서 구분해야 할것이 있다. 하나는 아키텍쳐 의존적인 부분과 아키텍쳐와 독립적인 부분이 있다. 리눅스는 가급적 아키텍쳐 독립적으로 구성되려고 노력한 흔적이 여기저기 보인다. 그래서 리눅스가 다른 아키텍쳐에 포팅 될수 있었던 것이다. 만약 PC의 i386계열에 의존적인 부분이 매우 많았다면 지금처럼 임베디드용으로 사용되지도 못했을 것이다. 자 커널을 이해하는 방법은 어떤게 좋을까? 어디까지 이해해야 할까? 이에 대한 나의 생각을 풀어 보겠다.
5.3 커널을 이해하기 위한 방법론 및 어디까지?
커널을 이해하기 위해서 가장 좋은 방법은 쏘스에서 흐름을 쭈욱 쫒아가 보는 것이다. 이를 위한 방법은 켈프에서 제안한 숙제중 부팅 메세지를 시리얼로 보내는 방법을 제안한다. 물론 이때 "Uinx kernel 완전분석으로 가는길이라는 책" 을 옆에 끼고 있는 것이 좋을 것이다. 물론 켈프에 조형기님이 진행하고 있는 강좌란도 무척 도움이 될것이다. 너무 완벽하게 쫒아 가려고 하지 않는 것이 좋을 것이다. 이 놈의 리눅스 커널을 쫒아 가는 것에 맛이 들리면 도통 헤어나질 못하게 된다. 필요한 만큼만 쫓아 다니면 된다. 임베디드 리눅스를 구현함에 있어서 대부분은 기존에 이미 포팅되어 있는 아키텍쳐를 이용하게 되는데 이 방법이 의미하는 것은 커널을 완벽하게 이해하기 보다는 커널 쏘스의 어떤 부분에 어떤 기능이 있는가 정도를 파악하는 선이면 된다는 것이다. 필요할때 좀더 자세하게 쏘스를 쫒아 다니면 된다. 또 내가 권유하는 방식은 당신이 필요로 하는 기능은 대부분 다른 사람이 이미 해 놓았을 가능성이 높다는 것이다. 커널에 집중하기 보다는 웹싸이트를 뒤지는 시간이 더 짧을 수 있다. 요즘은 Know Where!! 아닌가....

6. 정말 임베디드 리눅스를 하려면

5항까지 진행된 분이라면 6항 이후에 설명하는 과정을 수행해도 문제가 없을 것이다. 여기서 부터는 보통 일반인들이 말하는 임베디드 시스템용 리눅스를 어떻게 하는가를 설명하는 것이다.
6.1 평가 보드를 구매하라...
만약 당신이 가난한 개발자라면 이 이후에 진행은 포기해 달라.. 왜? 개인이 하기에는 너무도 벅찬 돈이 든다. 그냥 평가 보드만 사서 될일이 아니다. (이것도 정말 비싸다) 물론 평가 보드만 사도 될수 도 있지만 새로운 하드웨어적인 기능을 추가하고 시험하려면 개발 장비가 보통 고가가 아니다. 그냥 개인이 취미로 하기에는 이미 금전적인 부담이 넘어선다. 단 평가보드상에서 만족한다면 평가보드 살 능력이 되야 한다. 평가보드만으로도 꽤 많은 것을 공부 할수 있다. 단 평가보드를 구매할때 JTAG가 지원되는 평가보드를 구매하라 그나마 JTAG를 사용하는 공부는 돈이 적게 든다.
6.2 평가 보드를 구매 했다면....
평가 보드를 보통 구매하면 대부분의 문서가 따라 오게 된다. 물론 사용되는 디바이스의 설명서들이 포함되 있거나 최소한 어디서 구하는지에 대한 설명은 있을 것이다. 이런 자료를 모두 일단 확보할 것
6.3 MCU를 공부하라..
평가 보드에 사용되고 있는 MCU에 대해서 공부해야 한다. MCU를 모르고 임베디드를 도전하는 것은 시간낭비의 지름길이다. MCU의 구조 MCU의 하드웨어 사양 MCU의 프로그램 방법 ( 어셈블러 ) MCU의 동작 방식 뭐 이런 것이 있겠다.
6.4 평가 보드의 회로를 공부해라...
평가 보드의 회로를 읽는 법을 알아야 한다. 회로를 읽지 못하고 임베디드를 공부하려 한다면 진행하는데 한계를 느낄수 있다. 회로를 읽을수 있어야 외부 연결 커넥터에 어떻게 연결하는지를 이해 할수 있다.
6.5 평가 보드에 사용되는 디바이스를 공부해라...
평가 보드에 사용되는 디바이스를 모두 공부할 필요는 없다. 자신이 사용하고자 하는 디바이스에 대해서 하드웨어적으로는 어떻게 연결되고 디바이스를 제어하기 위해서는 소프트웨어 적으로 어떻게 해야 하는 가를 이해 해야 한다. 이런 이해를 위해서는 해당 디바이스에 대한 리퍼런스 매뉴얼의 확보는 필수적이다. 항상 나에 가슴을 아프게 하는 것은 기술된 언어가 영어라는 점이다. 빨리 한글이 전세계 공통어로 되어야 하는데.... 나를 세계 대통령으로 밀어 주면 가장 먼저 한글을 공용어로 하고 모든 표기를 한글로 하는 세계법을 제정하겠다.
6.6 크로스 컴파일 환경을 구축하는 것을 공부하라...
임베디드 리눅스를 공부하는 것에 가장 큰 관문중에 하나가 크로스 컴파일 환경을 구축하는 것이다. 그나마 다행인것은 요즘은 아예 rpm 패케지로도 나온다는 점이다. 그래도 몇몇 cpu에 필요한 환경은 자신이 스스로 구축해야 한다. 또 평가 보드에 따라 구축하는 방법이 조금씩 다를 수 있다. 물론 평가보드에 따라오는 CD에는 일반적으로 크로스 컴파일에 필요한 화일도 따라오므로 좀 괜찮기는 하지만 아예 공부하지 않으면 조금만 문제가 생겨도 속수 무책일수 있다.
6.7 부트 로더를 공부하라.
임베디드 리눅스를 공부하기 위해서 가장 처음 부딪히는 것이 부트 로더다. PC에서는 그 개념이 별로 중요하지 않으므로 이 문제가 별로 대두되지 않지만 임베디드에서는 바로 대두 된다. 보통은 이미 개발된 오픈된 부트 로더를 자신의 시스템에 맞게 바꾸게 된다. 그러므로 부트로더의 쏘스는 어느정도 분석하고 있어야 한다.
6.8 NFS 시스템에 대해서 공부하라...
임베디드 시스템에는 커다란 보조 기억 장치가 없기 때문에 필히 네트워크를 이용한 다른 시스템의 보조 기억 장치를 마운트 사용해야 편리하다. 이를 위해 사용되는 것이 NFS이다. 고로 이에 대한 공부는 해두는 것이 좋다.
6.9 그외 나머지는 어떻게?
커널을 올리고 바꾸고 하는 것은 PC에서 공부했다면 별로 문제가 되지 않는다. 또 대부분 커널은 포팅했다. 단 일반적으로 부딪히는 문제를 늘어 놓는다면 다음과 같다.
6.9.1 MMU가 없다..
보통 PC에서는 MMU가 있으므로 문제가 되지 않지만 임베디드 시스템에서는 MMU가 없는 것이 일반적이다. 왜? 가격이 싸기 때문이다. 그렇다면 어떤 문제가 있을까 바로 이 문제에 대해서 공부해야 한다는 것이다. 50100용을 사용하거나 드래곤볼 을 사용한 임베디드 리눅스의 하우투 문서를 찾아 보고서 공부하는 것이 좋다.
6.9.2 루트 디스크 이미지와 램 디스크
임베디드 리눅스의 거의 대부분이 보조 기억 장치가 없거나 있어도 플래쉬 메모리 이다. 그래서 루트와 마운트 되는 기억 장치로 램 디스크를 많이 사용하게 된다. 문제는 램 디스크용 루트 이미지가 ROM에 있거나 플래쉬 메모리에 저장되기 때문이다. 커널의 루트 이미지 복사는 부분에 대한 공부를 필요로 하는 것이 이 때문이다.
6.9.3 플래쉬 메모리에 대해서 공부 할것
플래쉬 메모리는 하드 디스크 처럼 쓰고 읽을 수 있는 저장 장치이다. 더구나 읽는 속도가 매우 빠르다. 그러나 플래쉬 메모리는 쓰는 횟수에 한계가 있다. 이에 대한 공부를 미리 하지 않으면 당신이 납품한 임베디드 장비에 대해서 고생 할 가능성이 농후하다. 이에 대하여 다른 사람은 어떤 방법론이 있는가에 대하여 미리 공부해 두는 것도 좋을 것이다. 가끔 배신감 느끼게 플래쉬에 대한 몇가지 소프트웨어가 특허에 걸려 있다.
6.9.4 계속 늘어 놓으면 한도 끝도 없을 것 같으므로 ...
정말이다.. 임베디드 리눅스라는 분야는 PC이외에 모두 다 라고 할 정도로 다양하다. 이 모든 것을 미리 공부할수는 없다. 역시 실전에 부딪히면서 배우는 수밖에 ....

7. 빨리 개발하는 방법....

아마도 이 글을 읽고서 벌써 임베디드 리눅스를 공부하고 싶은 마음이 없어지는 사람들의 목소리가 들린다. 음.... 아마도 이글을 읽고 있는 분들 중에는 당장 1달안에 개발을 완료 해야 하는 분들도 있을 것이다. 이에 대한 해답은 아니지만 속성 코스에 대해서 이야기 하려고 한다. 단 이 방법은 엔지니어로써 어느정도 구력이 있는 분에 해당하는 것이지 완전 엔지니어 초짜에 해당되는 것은 아님을 미리 밝힌다.
7.1 이미 개발된 평가 보드를 이용할 것...
자 임베디드 리눅스를 이용한 시스템을 만든다는 것은 자신이 목적으로 하는 동작이 정확하게 수행되면 된다. 그러므로 구현하고자 하는 장비와 최대한 같은 기능을 담고 있는 평가보드(개발보드) 를 구한다. 이 평가 보드에는 리눅스가 모두 설치 되어 있어야 한다. 그리고 캐랙터 디바이스의 가장 최소한에 대한 공부만 한다. 이것 마저도 안한다면 어쩔수 없다. 그리고 평가보드의 회로를 최대한 그대로 수용한 목적 시스템을 만든다. 이런 상태라면 다음과 같은 할일만 남는다.

1. 부트로더에서 초기화와 커널 부팅을 수행하는 부분만 남겨 놓고 제거한다.
2. 커널을 그대로 사용한다.
3. 대부분의 디바이스 드라이버도 그냥 사용한다.
4. 추가된 디바이스의 드라이버만 작성한다.
5. 어플리케이션을 작성한다.

이것이 끝이다.

8. 내가 하고 싶은 말은 ...

내가 제안한 초짜가 임베디드 리눅스로 가는 길이 맞다고는 할수 없다.

아직도 나는 초짜이므로

하지만 기존에 개발하는 과정을 지켜본 나로써 내린 것은 위와 같은 것이다. 누군가 말했다. 임베디드 리눅스의 세계에 발을 들여 놓는 순간은 태산을 삽질해서 없에는 것과 같다는 것을 하지만 내가 해본 결과로는 임베디드 리눅스를 한다는 것은 리눅스의 본질을 파악하는 것과 거의 일맥 상통한다. 엔지니어라면 한번쯤 도전해서 이루고 싶은 영역이다. 또 생각보다 재미 있다. 당신도 해보라... 겁만 먹지 말고 천천히 가다보면 언젠가 이미 득도한 해커와 같은 반석위에 있는 자신을 발견 할 수 있을 지도 모른다. 어느날 저녁 새벽 3시쯤 근방에 이글을 마무리 하며..... PS: 배고프다.... 그리고 졸립다....

'Computer Science' 카테고리의 다른 글

[summary] linux device driver  (0) 2009.08.12
Getting started with an embedded Linux system emulator  (0) 2009.08.09
리눅스 디바이스 드라이버 개요 및 실습  (0) 2009.08.02
엔터프라이즈, 아키텍쳐, 디자인패턴, 프레임워크  (0) 2009.07.18
아키텍쳐 서술의 추천 프랙티스  (0) 2009.07.18

리눅스디바이스드라이버

USB 디바이스드라이버

디바이스드라이버실습

출처:한국전자통신연구원 : ETRI

1249204875_05디바이스드라이버.pdf
1249204875_05디바이스드라이버.pdf

'Computer Science' 카테고리의 다른 글

Getting started with an embedded Linux system emulator  (0) 2009.08.09
[컬럼] 초보자를 위한 임베디드 리눅스 학습 가이드  (0) 2009.08.02
엔터프라이즈, 아키텍쳐, 디자인패턴, 프레임워크  (0) 2009.07.18
아키텍쳐 서술의 추천 프랙티스  (0) 2009.07.18
Plot Graphic Library  (0) 2009.07.16

<Enterprise>

■ 엔터프라이즈의 정의

<공동의 목표를 추구하기 위하여 기술의 지원 하에 정의된 절차를 수행하는 조직의 집합체 >

Zachman : 공통의 미션이나 목표를 지원하는 모든 통합된 비즈니스기능과 자산들의 집합

Spewak : 고객과 상품 및 서비스가 존재하며 이를 유지하고 지원하기 위한 내부 프로세스가 정립된 최소한의 단위

TOGAF(The Open Group Architecture Framework) : 공통의 목표를 가진 조직의 집합체

■ 엔터프라이즈의 의미

엔터프라이즈는 제품 및 서비스를 제공하기 위한 모든 비즈니스 활동을 포함해야 합니다.

따라서 엔터프라이즈의 구분은 비즈니스 단위나 사업부, 자회사 등으로 나누는 것이 적절하며, 부서(예:인사, 재무, 마케팅) 등의 조직을 단위로 구분하는 것은 적절치 못합니다.

하나의 기업 내에서 고객 층이 다르거나 다른 성격의 제품 / 서비스를 제공하는 글로벌 기업이나, 반대로 각 사의 핵심역량을 기반으로 다수의 기업이 공동으로 제품이나 서비스를 제공하는 경우, 엔터프라이즈의 범위를 단순히 하나의 기업으로 정의해서는 안됩니다,

즉 엔터프라이즈의 범위를 정의할 때는 엔터프라이즈의 계층과 e-비즈니스 환경을 고려하여 정의하여야 한다.

<아키텍쳐>

아키텍쳐 : 많은 사람들이 정의 하려고 애쓰는 용어이나 공통적인 요소 두가지

- 하나의 시스템을 여러부분으로 분리하는 가장 높은 수준의 분해

- 변경하기 어려움

프로그램 혹은 컴퓨팅 시스템의 소프트웨어 아키텍처란, 소프트웨어 컴포넌트, 이들 컴포넌트의 가시적인 속성, 그리고 컴포넌트 사이에 관계로 구성된 시스템의 전체적인 구조를 말한다. - Bass, Clements, Kazman, 1998 “Software Architecture in Practice”에서 발췌

소프트웨어 아키텍처는 한마디로 개발하려고 하는 소프트웨어의 큰 밑그림을 그리는 것으로 소프트웨어 개발에 직간접적으로 영향을 미치면서 복잡도를 높이는 다양한 요소들을 체계적으로 다루기 위한 청사진이라 할 수 있다.

소 프트웨어 아키텍처의 학술적인 정의는 소프트웨어를 구성하는 컴포넌트들, 이들간의 상호작용 및 관계, 각 컴포넌트(구성요소, 부품)들의 특성 및 이들이 구성하는 소프트웨어의 설계 및 진화를 위한 각종 원칙들의 집합이라고 할 수 있다.

실제적으로 아키텍처는 대상이 되는 시스템에 관련된 여러 이해관계자(stakeholder)의 관심사항과 이에 따른 관점을 반영한 다양한 모델들의 집합이 된다. - 한국정보통신기술협회, 2004 “소프트웨어 아키텍처 연구 분야 및 IEEE 1471 국제표준” 에서 발췌

<디자인패턴>

- 패턴들은 시작점을 제공하는 데 도움을 주기 위해 작성된 것
- 모든 패턴은 불완전하며 이것을 완성하는 책임과 즐거움은 모두 여러분의 몫이라는 점을 항상 기억바람

> 패턴(Pattern)
어떤 작업을 할 때 같은 유형의 형태를 계속 적으로 반복하여 사용하게 되는데 이렇게 같은 형태를 반복적으로 사용하는 것을 어떤 작업에 대한 패턴이라 한다. 프로그램에도 이 같은 패턴이 적용 된다. 최근의 경향인 프레임워크(framework)의 설계를 위해서 또 융통성 있고 재사용성을 가진 소프트웨어 시스템의 개발을 위해서는 지금까지 제안된 다양한 설계 패턴을 활용할 필요가 있습니다. 범용적으로 제안된 23개의 Design Pattern이 있다.

> 생성 패턴 (Creational Pattern) - 5개

Abstract Factory, Builder, Factory Method, Prototype, Singleton
최 근의 객체지향 애플리케이션의 경우 적용 분야나 대상에 따라서 새로운 객체를 생성하고 이로부터 새로운 인스턴스들을 생성해야 새로운 애프리케이션을 손쉽게 개발 할 수 있다.Creational Pattern은 인스턴스화 과정을 추상화하여 시스템이 객체의 생성과 조합 및 객체 표현 방법에 독립적으로 개발할 수 있도록 지원한다. 클래스 Creational Pattern은 인스턴스화될 클래스를 다양화 하기 위해서 상속(inheritance)을 활용해야 한다.

> 구조적 패턴 (Structural Pattern) - 7개
Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy

Structural Pattern은 객체와 클래스가 하나의 복잡한 구조를 어떻게 형성하는 가의 방법에 관한 패턴이다. 구조적 클래스 패턴은 interface나 implementation을 합성하기 위해서 상속(inheritance)을 사용한다. 객체의 구성이나 interface를 합성하기 보다는 Structural Pattern을 이용하여 새로운 기능성을 실현하는 복합 객체(Complex Object)를 작성할 수 있는 방법이 더 효과적이다.

> 행위적 패턴 (Behavioral Pattern) - 11개
Chain of Responsilbility, Command, Interpreter, Iterator, Mediator, ... 등

Behavioral Pattern은 객체들간에 행위의 할당이나 알고리즘과 관련된 패턴이다. 최근의 소프트웨어들은 응용 분야에 따라 행위가 다른 객체로 옮겨 가거나 알고리즘이 대체되는 경우가 존재하게 마련이다. 이러한 변화의 개념을 잘 만족할 수 있는 것이 Behavioral Pattern이다. Behavioral Pattern은 객체나 클래스에 대한 패턴을 정의하는 것이 아니라 그들간의 교류 방법에 대하여 정의하는 것이다. 이러한 패턴은 실행시에 수행하기 어려운 제어 구조를 정의할 수 있다. 클래스간의 행위적 차이를 정의하기 위해서 상속(inheritance)을 사용할 수도 있지만 이보다는 객체 합성을 사용하여 처리한다

[출처] 엔터프라이즈, 아키텍쳐, 디자인패턴, 프레임워크|작성자 블루버드

'Computer Science' 카테고리의 다른 글

[컬럼] 초보자를 위한 임베디드 리눅스 학습 가이드  (0) 2009.08.02
리눅스 디바이스 드라이버 개요 및 실습  (0) 2009.08.02
아키텍쳐 서술의 추천 프랙티스  (0) 2009.07.18
Plot Graphic Library  (0) 2009.07.16
LUA[강좌] C,C++ 을 아는사람을 위한. 루아의 시작..  (0) 2009.06.28

출처 : http://2005elc.elancer.co.kr/eTimes/page/eTimes_printFm.html?str=c2VsdW5vPTg0Ng==

1.아키텍쳐 서술의 추천 프랙티스 2005/12/13

　IT시스템에 대한 요구의 다양화, 아키텍쳐의 대규모화와 복잡화에 대응하기 위해서는 현실 세계나 시스템화 대상을 다양한 각도로 표현하는 방법이 필요하다. 이번엔 Zachman 체제나 UML의 각종 다이어그램 등에도 볼 수 있는 시스템 표현의 체계화 기반기술의 하나인「뷰포인트」를 취급한다.

　뷰포인트는 시스템 표현 모델의 적절한 이용 문맥을 정의하는 시점이라고 할 수 있다. 이것은 IT시스템의 stakeholder(이해관계자)에 대해서 적절한 문맥으로 시스템 표현을 실시하기 위해서 필요한, 시스템 표현 모델 체계화의 골조를 정의한다.

　아키텍트가 UML을 이용해 시스템 구축을 하는 경우,「어느 UML 다이어그램을 어느 순서로 정의해 나가야 할까」를 결정하는 골조가 개발 방법론이다. 아키텍트는 경험 원칙이나 채용하는 개발 방법론에서 정해진 순서에 따른다. 뷰포인트는 이러한 경험 원칙이나 프랙티스에 따르는 부분을 가능한 한 명확하게 정의된 골조를 준비해, 소프트웨어 개발에 공학적 어프로치를 적용해 나가려는 컨셉이있다.

◆아키텍쳐 서술의 추천 프랙티스

　소프트웨어 아키텍쳐에는 다양한 정의가 존재한다. 그 이유는 아키텍쳐를 표현하는 방법이 한개로는 정해지지 않기 때문이다. 아키텍쳐 자체가 복수의 각도에서 표현을 조합하지 않으면 엄밀한 정의를 할 수 없는 이유때문이다.

　건축물을 설계하는 경우, 통상 3 방향에서 본 시점에서의 도면이 필요하다. 또, 상세한 구조도, 배수관이나 전기 배선도, 소재나 부품표 등 많은 부대적인 도면도 필요하다. 시각적으로 뛰어난 관점에서는, 입체적인 3 차원 도면도 있으면 더욱 좋을 것이다. 이와 같이 완성해야 할 물리적인 건축물은 한개여도, 그것을 적절히 표현하기 위한 도면은 한개가 아니다.

　그러면 어떤 도형을 사용할지, 복수의 도형을 어떻게 조합할지를 명확하게 규정하려면 어떻게 해야 할까. 각각의 도형은 그 도형으로 표현하고 싶은 관심사로 한정하고 다른 관심사는 무시하면 된다. 예를 들면, 지하철 노선도는 지하철의 경로만을 취급하고 지상에 존재하는 도로나 건물의 정보를 취급하지 않는다. 이것은 일종의 관심 분리이다.

　같은 아키텍쳐의 표현에서도 구조를 취급하는 표현, 행동을 취급하는 표현, 배치를 취급하는 표현등이 존재한다. 이러한 관심을 분리 해서 각각의 관심에서 적절한 다이어그램을 적용할 것이 요구된다. 그것을 위해서 UML에서는 많은 다이어그램이 준비되어, Zachman 체제에서 많은 관심을 체계화하는 골조가 정해져 있다.

　이러한 기술 배경에 따라 관심 분리의 원칙과 stakeholder의 시점을 고려해 아키텍쳐 서술을 정의하고 있는 것이, IEEE std 1471-2000아키텍쳐 서술의 추천 프랙티스이다.

●IEEE std 1471-2000아키텍쳐 서술의 개념 모델

　그러면 우선 이 IEEE std 1471-2000의 아키텍쳐 서술을 보자.

그림 1 IEEE std 1471-2000의 아키텍쳐 서술의 개념 모델
모델도로 기록되고 있는 키 컨셉(Stakeholder나 Concern등)의 의미에 대해서는 이후에 게재하는 표 1을 참조해 주었으면 한다. 이 개념 모델을 간단하게 설명하면 다음과 같이 된다.
Stakeholder(이해관계자)의 Concern(관심)의 표현은, 그것을 표현하는 Model(모델) 정의를 규정하는 Viewpoint(뷰포인트)를 선택해 실시한다. 즉,
1. Stakeholder(이해관계자)는 1개이상의 Concern(관심)을 가지고 그러한 Concern을 표현하기 위한 Viewpoint(뷰포인트)를 선택한다.
2. Viewpoint의 선택은 Concern을 표현하는 Model(모델) 정의의 규정을 부여할지 말지를 판단해서 결정한다. 이 Viewpoint는 Concern의 표현에 적절한 관심 분리를 부여하는 Library Viewpoint(라이브러리화 된 뷰포인트)에서선택한다. 복수의 Mission(목적)을 가진 Environment(제약 조건)를 가지는 System(시스템화 대상)에 대한 Architecture(아키텍쳐)를 구축한다. 구축되는 Architecture는 Architecture Description(아키텍쳐 서술)로 정의된다. 아키텍쳐의 정의에는 정의 한 아키텍트가 설명 책임을 가진 Rationale(이유 부여)을 수반한다. 여기서,
3. 아키텍쳐(Architecture)는 복수의 Model를 사용한 View(뷰)로서 표현된다.
4. 게다가 복수의 View로 아키텍쳐가 기술되어(Architectural Description), Model 정의의 규정을 부여하는 Viewpoint에 의해서 View는 관심 분리의 원칙에 따른다.
5. Viewpoint에 의한 관심의 분리는 Stakeholder의 다차원적인 요구에 골조를 부여한다.
Software Factories는 이 일련의 Viewpoint 골조를 개발 기반기술에 적용하고 있다.

　그림 1은 IEEE std 1471-2000의 아키텍쳐 서술의 개념 모델을 정의하고 있다.

　이 그림에서는 키 컨셉과 그 관계를 메타 모델 표현으로서 정의하고 있다. 이 모델 자체는 어느 시스템이 단일 아키텍쳐로 구축되는지, 한 아키텍쳐가 단일 아키텍쳐 서술로 정의되는 지도 가정하고 있지 않다. 즉 시스템이 복수 아키텍쳐, 예를 들면 파이프라인과 이벤트 드리븐 아키텍쳐로 구축되어도, 각각의 아키텍쳐의 기술법을 통일해야 하는 강제력을 가지지 않는다.

　그림 1의 키 컨셉을 정리한 것이 다음의 표 1이다.

키 컨셉의미
Stakeholder：
이해관계자		시스템의 아키텍쳐의 이해관계자 .예를 들면 아키텍트, 프로그래머, 시스템 운용자, 데이타베이스 관리자, 최종 사용자, 경영자, 프로젝트 매니저, 비즈니스 분석자 등. 각각 다른 관심을 가지고 있어, 서로의 요구에 모순이나 부정합이 존재한다
Concern：
관심		기능 요구와 비기능 요구, 정적인 구조와 동적인 동작, 개념/논리/물리 레벨의 관점, 표시와 정보, 시큐러티나 성능, 서비스 내용과 서비스 배치 등, 개발과 관계되는 요소, 조건을 분할해 고려하는 경우의 스코프
Viewpoint：
뷰포인트		뷰를 기술, 분석하기 위한 모델(뷰포인트 언어)과 모델에 적용하는 모델링 수법, 분석 수법등의 규정. 아키텍쳐 서술에서는 1개이상의 뷰포인트을 선택한다
View：
뷰		(복수의) stakeholder의 (복수의) 관심에서 본 시스템 전체의 표현. 1개이상의 모델로 표현된다
Model：
모델		기법. 예를 들면 UML 다이어그램, DSL등의 표현. 1개이상의 뷰에 속하는 것도 있다
표 1 IEEE std 1471-2000의 키 컨셉(발췌)

　예를 들면, Web 어플리케이션에서 구축되는 서적 구입 사이트는 아키텍트의 관심으로서, Web 서버상의 UI프로세스, Web 페이지 레이아웃 정의, 비즈니스 논리의 컴퍼넌트 구조, 비즈니스 논리의 오브젝트의 순서(동작), 컴퍼넌트 배치, 데이터 액세스층, 데이타베이스의 테이블 정의등에서 구축된다.

　이 경우에는 UI프로세스등이 모델로, 이러한 모델을 모아 아키텍쳐가 서술된다. 모델은 복수의 stakeholder의 관심의 표현과 관계된다. 여기서의 컴퍼넌트 배치 모델은 아키텍트의 관심 모델로서 뿐만이 아니라 시스템 운용자의 관심 모델로서도 이용된다.

◆stakeholder에 의한 관심 분리

　여기서 좀 더 stakeholder의 관심의 표현을 보고 가자. 그림 2는 stakeholder에 의한 관심 분리의 예이다. 이 그림에서는 각각의 stakeholder의 역할에 따라서 필요로 하는 아키텍쳐 서술의 표현법이 다른 것을 나타내고 있다.

그림 2 stakeholder에 의한 관심의 분리
stakeholder의 역할에 따라 관심이 다르기 때문에 그 관심을 표현하는 모델도 다르다. 이 예에서는 비즈니스 분석자의 관심인 비즈니스 요구를 개념 레벨의 유스 케이스 모델로 표현한다. 같이 프로그래머는 구현해야 할 코드의 논리 모델을 구현에 활용한다. 데이타베이스 관리자는 관리 대상 데이타베이스의 데이터 모델로부터 데이터 구조를 파악한다.

　아래와 같이 stakeholder의 관심은 다양한 관점으로 분류할 수 있다.

(1) 관심을「정적 구조와 동적 행동」으로 분류하면 정적 구조에서는 아키텍트의 관심을 표현하는 비즈니스 논리의 컴퍼넌트 구조나, 시스템 운용자의 관심을 표현하는 컴퍼넌트 배치가 포함된다. 또, 동적 동작에는 아키텍트의 관심을 표현하는 비즈니스 논리의 오브젝트 순서도나, 시스템 운용자의 관심을 표현하는 메세지 제휴가 포함된다.

(2) 관심을「정보 도메인」으로 분류하면 아키텍트의 관심을 표현하는 데이타베이스 테이블 정의나, 비즈니스 분석자의 관심을 표현하는 정보 엔티티이다.

(3) 관심을「논리 레벨과 물리 레벨」로 분류하면 논리 레벨에는 아키텍트의 관심을 표현하는 비즈니스 논리의 컴퍼넌트 구조가 포함되고, 물리 레벨에는 데이타베이스 관리자의 관심을 표현하는 데이타베이스 정의가 포함된다.

　이것들 3 종류의 관심의 분류법은 각각

(1) UML 다이어그램의 정적/동적 모델(=정적 구조와 동적 동작)

(2) EA(Enterprise Architecture)의 비즈니스/정보/어플리케이션/기반구조(=정보 도메인)

(3) 개발 라이프 사이클의 개념/논리/물리 레벨

로 관심을 분류해 stakeholder의 관심 모델을 선택해서 표현하는 예이다.

　관심 분류법을 이정도로 한정하지 말고 아키텍쳐 서술에 적절한 관심을, 적절한 분류법을 기준으로해서 선택하면 좋겠다*1. 이 분류법은 아키텍쳐 서술에 필요한 모델의 편성을 규정하는 뷰포인트가 결정한다.

*1 예를 들면, Philippe Kruchten씨의 “4+1” 뷰 모델( 「The 4+1 View Model of Architecture」, IEEE Software, vol. 12, No. 6, November 1995, pp. 42-50이나 ISO/IEC 10746-2의 「Reference Model for Open Distributed Processing」(RM-ODP)은 다른 분류법을 정의하고 있다.

'Computer Science' 카테고리의 다른 글

리눅스 디바이스 드라이버 개요 및 실습  (0) 2009.08.02
엔터프라이즈, 아키텍쳐, 디자인패턴, 프레임워크  (0) 2009.07.18
Plot Graphic Library  (0) 2009.07.16
LUA[강좌] C,C++ 을 아는사람을 위한. 루아의 시작..  (0) 2009.06.28
프로그래밍 언어 Mini-HOWTO  (0) 2009.06.21

+ Recent posts

티스토리툴바