Developer Log
  • Wiki
  • Books
    • 리눅스 시스템 프로그래밍
      • 핵심 개념 소개
        • 시스템 프로그래밍
        • API와 ABI
        • 리눅스 프로그래밍의 개념
          • 파일과 파일시스템
          • 프로세스
          • 사용자와 그룹
          • 권한
          • 시그널
          • 프로세스간 통신
          • 에러 처리
    • 데이터 베이스 첫걸음
      • 데이터베이스란
        • 데이터베이스의 역할을 생각해 보자
          • 우리와 데이터베이스의 관계
          • 데이터베이스의 기본 기능
          • 데이터베이스 종류
      • 관계형 데이터베이스란
        • 대표적인 DBMS를 알아보자
          • 관계형 데이터베이스란
          • SQL 기초 지식
          • 관계형 데이터베이스를 다루기 위한 사전 지식
      • 데이터베이스에 얽힌 돈 이야기
        • 초기비용과 운영비용을 생각하자
      • 데이터베이스와 아키텍처 구성
        • 다중화에 대해 생각해보자
          • 아키텍처란
          • 데이터베이스의 아키텍처
            • 역사와 개요
              • Stand-alone
              • 클라이언트/서버
              • Web 3계층
            • 가용성과 확장성의 확보
          • DB 서버의 다중화
            • 클러스터링
            • 리플리케이션
          • 성능을 추구하기 위한 다중화 - Shared Nothing
          • 적합한 아키텍처를 설계하기 위해
      • DBMS를 조작할 때 필요한 기본 지식
        • MySQL 설치해보자
        • MySQL과 커넥션 만들기, 데이터베이스에 전화걸기
        • SQL과 관리 명령의 차이
        • 관계형 데이터베이스의 계층
      • SQL 문의 기본
        • SELECT 문으로 테이블 내용을 살펴보자
        • SELECT 문을 응용해보자
        • 데이터를 갱신, 삽입, 제거해보자
        • 뷰를 작성하고 복수 테이블에서 선택해보자
      • 트랜잭션과 동시성 제어
      • 테이블 설계의 기초
      • 백업과 복구
      • 성능을 생각하자
    • 개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴
      • 객체 지향
        • 들어가기
        • 객체 지향
        • 다형성과 추상 타입
        • 재사용: 상속보단 조립
      • 설계 원칙 / DI와 서비스 로케이터
        • 설계 원칙: SOLID
          • 단일 책임 원칙(Single Responsibility Principle)
          • 개방 폐쇄 원칙(Open - Closed Principle)
          • 리스코프 치환 원칙(Liskov Substitution Principle)
          • 인터페이스 분리 원칙(Interface Segregation Principle)
          • 의존 역전 원칙(Dependency Inversion Principle)
          • SOLID 정리
        • DI(Dependency Injection)와 서비스 로케이터
      • 주요 디자인 패턴
        • 디지인 패턴이란?
        • 전략(Strategy) 패턴
        • 템플릿 메서드(Template Method) 패턴
        • 상태(State) 패턴
        • 데코레이터(Decorator) 패턴
        • 프록시(Proxy) 패턴
        • 어댑터(Adapter) 패턴
        • 옵저버(Observer) 패턴
        • 미디에이터(Mediator) 패턴
        • 파사드(Facade) 패턴
        • 컴포지트(Composite) 패턴
        • 널(Null) 객체 패턴
        • 팩토리 메서드 패턴
        • 커맨드 패턴
        • 추상 팩토리 패턴
    • 테스트 주도 개발
      • 1부
        • 다중 통화를 지원하는 Money 객체
        • 타락한 객체
        • 모두를 위한 평등
        • 프라이버시
        • 솔직히 말하자면
        • 돌아온 '모두를 위한 평등'
        • 사과와 오렌지
Powered by GitBook
On this page
  • API
  • ABI

Was this helpful?

  1. Books
  2. 리눅스 시스템 프로그래밍
  3. 핵심 개념 소개

API와 ABI

시스템 레벨에서 호환성에 영향을 주는 두 가지는 API(Application Programming Interface) 와 ABI(Application Binary Interface) 이다.

API

API는 소프트웨어의 소스 코드 레벨에서 서로 인터페이스 하는 방식을 정의한다. 일반적으로 API 표준 인터페이스는 함수이며 상위 레벨의 소프트웨어에서 하위 레벨의 소프트웨어를 호출할 수 있다.

API는 인터페이스를 정의하며 그 정의를 실제로 구현한 소프트웨어를 API 구현체라고 한다.

API는 양쪽 소프트웨어 모두가 API 를 준수할 경우에만 동작하며 소스 코드 수준에서 호환된다. 즉, API의 구현체와 관계없이 해당 API를 따르기만 한다면 성공적으로 컴파일된다.

ABI

API가 소스 코드 수준의 인터페이스를 정의한다면, ABI는 특정 아키텍처 간에서 동작하는 소프트웨어 간의 바이너리 인터페이스를 정의한다.

API가 소스 코드 수준의 호환성을 보장한다면, ABI는 바이너리의 호환성을 보장하여 오브젝트 코드를 다시 컴파일하는 수고 없이 같은 ABI를 지원하는 시스템이라면 동일한 기능을 수행하도록 보장한다.

리눅스를 포함한 운영체제는 각각의 요구사항에 부합하는 고유의 ABI를 정의하려는 경향이 있다. ABI는 아키텍처와 밀접한 관계가 있으며, ABI 대부분은 특정 레지스터나 어셈블리 명령어 같은 하드웨어에 국한된 개념을 다루고 있다. 따라서, 리눅스에서는 아키텍처마다 다른 고유의 ABI를 가지고 있다.

Previous시스템 프로그래밍Next리눅스 프로그래밍의 개념

Last updated 6 years ago

Was this helpful?