네트워크 인터페이스가 다른 장치처럼 /dev에 위치하지 않는 이유는 무엇입니까?

네트워크 인터페이스가 다른 장치처럼 /dev에 위치하지 않는 이유는 무엇입니까?

궁금한데 네트워크 인터페이스가 왜 /dev에 없나요? /dev 아래에 노드로 표시되지 않는 다른 유형의 장치가 있습니까?

답변1

많은 장치에서 기본 작업은 컴퓨터에서 주변 장치로 바이트를 보내거나 컴퓨터의 주변 장치에서 바이트를 받는 것입니다. 이러한 장비는 파이프와 유사하며 잘 작동합니다.캐릭터 장치. 읽기 및 쓰기가 아닌 작업(예: 직렬 회선의 흐름 제어)의 경우 장치는 다음을 제공합니다.I/W 제어.

일부 장치는 일반 파일과 매우 유사합니다. 제한된 수의 바이트로 구성되어 있으며 특정 위치에 쓴 내용을 나중에 동일한 위치에서 읽을 수 있습니다. 이러한 장치를 호출합니다.블록 장치.

네트워크 인터페이스는 더 복잡합니다. 바이트가 아닌 패킷을 읽고 씁니다. 및 의 일반적인 인터페이스를 사용하는 것이 여전히 가능하지만 read이는 write어색할 수 있습니다. 아마도 write호출당 하나의 패킷이 전송되고 read호출당 하나의 패킷이 수신될 것입니다(그리고 버퍼가 너무 작아서 패킷을 담을 수 없으면 패킷이 손실됩니다). ).

네트워크 인터페이스는 실제로 제공될 수 있습니다 ioctl. 실제로 일부 UNIX 변형에서는 이를 수행하지만 Linux에서는 그렇지 않습니다. 이 접근 방식에는 몇 가지 장점이 있습니다. 예를 들어 Linux에서는 네트워크 인터페이스가 이점을 누릴 수 있습니다.우데브. 하지만 장점이 제한적이어서 아직 해보지 못했습니다.

대부분의 네트워크 관련 애플리케이션은 개별 네트워크 인터페이스에 관심이 없으며 더 높은 수준에서 작동합니다. 예를 들어, 웹 브라우저는 TCP 연결을 설정하려고 하고, 웹 서버는 TCP 연결을 수신하려고 합니다. 이를 위해 다음과 같은 높은 수준의 네트워크 프로토콜을 위한 장치가 유용합니다.

{ echo $'GET http://www.google.com/ HTTP/1.0\r';
  echo $'Host: www.google.com\r';
  echo $'\r' >&0; cat; } <>/dev/tcp/www.google.com/80

실제로 ksh와 bash는 TCP 및 UDP 클라이언트에 이러한 인터페이스를 제공합니다. 그러나 일반적으로 네트워크 애플리케이션은 파일 액세스 애플리케이션보다 더 복잡합니다. 대부분의 데이터 교환은 read및 와 같은 호출을 통해 이루어지지만 write연결을 설정하려면 파일 이름보다 더 많은 정보가 필요합니다. 예를 들어, TCP 연결을 수신하려면 두 단계가 필요합니다. 첫 번째 단계는 서버가 수신을 시작할 때 수행되고, 두 번째 단계는 클라이언트가 연결할 때마다 수행됩니다. 이러한 추가 단계는 파일 API와 잘 맞지 않습니다. 이것이 네트워크가 자체 API를 갖는 주된 이유입니다.

일반적으로 Linux에 항목이 없지만 /dev다른 UNIX 변형에는 항목이 있는 또 다른 유형의 장치는 비디오 어댑터입니다. 원칙적으로 간단한 비디오 어댑터는 다음과 같이 노출될 수 있습니다.프레임버퍼장치는 각 픽셀의 색상을 나타내는 블록으로 구성된 블록 장치일 수 있습니다. 가속 비디오 어댑터는 응용 프로그램이 명령을 보내는 문자 장치로 표시될 수 있습니다. 여기서 장치 인터페이스의 단점은 속도가 느리다는 것입니다. 디스플레이 응용 프로그램(실제로는 X 서버)은 무엇이든 표시하기 전에 커널 호출을 해야 합니다. 대신 X 서버는 더 빠르기 때문에 주로 비디오 어댑터의 메모리에 직접 씁니다.

답변2

/sys/class/net카탈로그에서 만나보실 수 있습니다. 이는 다른 파일에 대한 심볼릭 링크이며 /sys/device/../../아래는 내 가상 머신(Linux 커널 3.10)의 출력입니다. 해당 속성 은 다음 명령을 사용 udevadm info <filename>하여 볼 수 있습니다.

lrwxrwxrwx. 1 root root 0 Apr  3 13:38 ens33 -> ../../devices/pci0000:00/0000:00:11.0/0000:02:01.0/net/ens33

답변3

TCP/IP 네트워킹을 수행하는 AT&T/Solaris "전송 수준 인터페이스"(TLI) 방식에는 "/dev/tcp" 또는 "/dev/udp"와 같은 특수 파일이 있습니다. 프로그래머는 적절한 프로토콜 계열에 대한 소켓을 얻기 위해 이 특수 파일을 엽니다. 이것이 바로 Solaris에서 소켓을 사용하는 프로그램을 컴파일할 때 "-lnsl"이 필요한 이유라고 생각합니다. 그 아래에는 모두 TLI가 있습니다.

답변4

전통적으로 Linux는 아직 posix와 완전히 호환되지는 않았지만 모든 종류의 Open Group 표준(LSB 제외)을 준수하는 것은 말할 것도 없습니다. 더 많은 UNIX 기능을 Linux로 이식하려는 시도가 있었습니다.

Glendix는 설명하는 작업을 수행할 수 있도록 하는 Plan9의 /net 가상 파일 시스템 포트를 제공하는 프로젝트 중 하나입니다.

Plan9는 /net 파일 시스템을 Linux로 포팅합니다.

관련 정보