N_TTY 는 수많은 ldisc 드라이버들 중의 하나일 뿐입니다.
더 궁금하시면 tty_register_ldisc() 를 사용하는 놈들을 검색해보시면 되고요.
어플리케이션의 도움이 필요하긴 합니다.
/dev/ttyX 따위를 열어서 baudrate 등등 설정하고 N_TTY 에서 N_HCI 나 N_MOUSE, N_PPP 따위로 바꿔야해서요.
이것마저 커널에서 해야겠다면, 불가능하진 않을 것 같습니다.
해본 적은 없지만, filp_open/do_vfs_ioctl/filp_close 정도면 충분하겠죠.
이런 목적이 아니라 tty 를 스니핑하거나 할 용도라면,
다른 사이트의 적절한 게시판을 뒤져보세요.
한 개의 UART 포트를 여러 디바이스에서 공유해서 쓸 수 있도록 하기 위해
새로운 ldisc 드라이버를 개발 중에 있습니다.
결국 하나의 write queue를 사용하여 write를 관리해주고 있습니다.
그런데 이때 N_HCI처럼 user-space 영역에서는 read/write 가능하도록
현재 커널 드라이버에 구현되어 있어 참조하고 있습니다.
그러나 user-space가 아닌 kernel-space에서 해당 uart port에
대한 read/write를 하려고 하는데 write 기능은 있으나
tty 같은 경우 별도의 read 함수가 제공되지 않아서
kernel-space 상에서의 uart-port에 대한 read 함수 구현이 애매해서요.
이와 관련된 사항이 위에서 알려주신 아래 함수들과 연관이 있는지 찾아봐야겠네요.
filp_open/do_vfs_ioctl/filp_close
추가적으로 ldisc 드라이버에 대한 정보가 부족하여
직접 소스 코드 분석을 통해서 스터디를 하고 있습니다.
혹시 ldisc 드라이버 관련하여 스터디 할 만한 자료가 있으시면 공유 부탁드리겠습니다.
경우는 좀 다른 것 같은데, 비슷한 상황을 겪은 적은 있습니다.
GSM 모뎀이었던 것 같은데.. 제 담당이 아니었습니다.
그 머 GPRS 던가 하는 놈을 사용하면 모뎀과의 데이터통신(메모리버스로 연결)이 마치 io버스처럼 사용되어 네트웍패킷을 포함한 모든 데이터가 지나다니더군요.
모뎀과의 연결이 메모리버스(dual port ram)이었었고,
GPRS 인가 뭔가하는 놈이 활성화되기 전엔 일반적인 AT모뎀 처럼 동작해야했기에,
유저 인터페이스는 tty 로 만들어주고,
GPRS 가 활성화된 후 네트웍과 기타등등을 모두 커널 모드에서 별도 장치 드라이버로 빼기 위해...
ldisc 가 아니라 다른 방법을 사용하셨던 것 같습니다.
제 기억엔 /dev/ttyXX 를 filp_open() 해서 vfs_read/write 를 사용하셨던 것으로 기억합니다.
vfs_read() 로 패킷 받아서 헤더 까보고 데이터만 각 장치로 나눠주고,
각 장치에서 올라온 데이터에 헤더 적절히 붙여서 vfs_write() 하는 걸 봤던 기억이 납니다.
각설하고,
tty_struct.ops->write() 는 있는데 read() 는 어딨느냐는 뜻의 질문인가요 ?
ldisc.receive_buf 콜백이 그 역할을 합니다.
receive 는 디바이스 쪽에서 발생하는 이벤트이므로 드라이버 측에서는 콜백을 제공하는 게 자연스럽지 않습니까 ?
개발한 ldisc 드라이버의 ldisc.receive_buf 함수를 통해서 user-space 까지는
데이터가 정상적으로 올라가는 것을 확인하였습니다.
"receive 는 디바이스 쪽에서 발생하는 이벤트이므로 드라이버 측에서는 콜백을 제공하는 게 자연스럽지 않습니까 ?"
위에서 말씀하신 이 부분이 저도 지금 애매하더라구요.
코드 분석을 해보니 irq를 통해서 receive_buf 함수가 호출되는 것으로 확인했습니다.
그렇기에 직접 receive_buf함수를 호출은 할 수 없을거 같아서요.
그럼 이때 irq를 통해서 irq handler에 의해서 callback함수로 새로 구현한 receive_buf 함수를 등록해줘서
해야 하는가 의문이 들고요. 추가적으로 이때 사용할려는 irq는 이미 tty framework에서
사용되는 부분이라서 어떻게 사용을 해야하는지에 대해서 의문점이 들어서요.
"누가 어디로부터 뭘 read" 해야하는 건지 정리 좀 해주세요.
왜 'user-space 까지는 데이터가 정상적으로 올라가는 것을 확인' 해야 하는지 궁금합니다.
제 기억에, 이게 되려면 ldisc.read() 를 작성하셔야 가능합니다.
게다가 ldisc.receive_buf() 에서 받은 데이타를 어딘가에 보관하고 ldisc.read() 가 그걸 읽어가야하죠.
이걸 하셨다면, 왜 다른 커널 모드 드라이버로 데이타를 넘기는게 헷갈리시나요 ?
똑같이 어딘가에 보관하고 있다가 다른 커널 모드 드라이버가 읽어가게 하던가,
다른 커널 모드 드라이버의 특정 함수를 호출해서 데이타를 넘겨주던가 하면 되는데요.
혹 ttyS0 를 타겟으로 삼아 ttyVS0~4 같은 가상의 장치를 만드는 게 목표인가요 ?
드라이버가 두 개 필요합니다.
mux/demux(혹은 duplicate)를 담당할 ldisc 드라이버와 유저 입출력을 담당할 ttyVS 드라이버.
ttyVS 드라이버는 실제 장치대신 작성하신 ldisc 드라이버와 데이타를 주고 받고,
유저와 ttyVS 드라이버 사이엔 기존의 n_tty ldisc 가 사용됩니다.
... 목적을 구체적으로 적어주시면 안되겠습니까
... 목적을 구체적으로 적어주시면 안되겠습니까 ?
N_TTY 는 수많은 ldisc 드라이버들 중의 하나일 뿐입니다.
더 궁금하시면 tty_register_ldisc() 를 사용하는 놈들을 검색해보시면 되고요.
어플리케이션의 도움이 필요하긴 합니다.
/dev/ttyX 따위를 열어서 baudrate 등등 설정하고 N_TTY 에서 N_HCI 나 N_MOUSE, N_PPP 따위로 바꿔야해서요.
이것마저 커널에서 해야겠다면, 불가능하진 않을 것 같습니다.
해본 적은 없지만, filp_open/do_vfs_ioctl/filp_close 정도면 충분하겠죠.
이런 목적이 아니라 tty 를 스니핑하거나 할 용도라면,
다른 사이트의 적절한 게시판을 뒤져보세요.
ldisc 드라이버 개발
먼저 답변 감사드립니다.^^
한 개의 UART 포트를 여러 디바이스에서 공유해서 쓸 수 있도록 하기 위해
새로운 ldisc 드라이버를 개발 중에 있습니다.
결국 하나의 write queue를 사용하여 write를 관리해주고 있습니다.
그런데 이때 N_HCI처럼 user-space 영역에서는 read/write 가능하도록
현재 커널 드라이버에 구현되어 있어 참조하고 있습니다.
그러나 user-space가 아닌 kernel-space에서 해당 uart port에
대한 read/write를 하려고 하는데 write 기능은 있으나
tty 같은 경우 별도의 read 함수가 제공되지 않아서
kernel-space 상에서의 uart-port에 대한 read 함수 구현이 애매해서요.
이와 관련된 사항이 위에서 알려주신 아래 함수들과 연관이 있는지 찾아봐야겠네요.
filp_open/do_vfs_ioctl/filp_close
추가적으로 ldisc 드라이버에 대한 정보가 부족하여
직접 소스 코드 분석을 통해서 스터디를 하고 있습니다.
혹시 ldisc 드라이버 관련하여 스터디 할 만한 자료가 있으시면 공유 부탁드리겠습니다.
comment 부탁드리겠습니다.
즐거운 하루 되세요. 최찬우입니다.^^
경우는 좀 다른 것 같은데, 비슷한 상황을 겪은 적은
경우는 좀 다른 것 같은데, 비슷한 상황을 겪은 적은 있습니다.
GSM 모뎀이었던 것 같은데.. 제 담당이 아니었습니다.
그 머 GPRS 던가 하는 놈을 사용하면 모뎀과의 데이터통신(메모리버스로 연결)이 마치 io버스처럼 사용되어 네트웍패킷을 포함한 모든 데이터가 지나다니더군요.
모뎀과의 연결이 메모리버스(dual port ram)이었었고,
GPRS 인가 뭔가하는 놈이 활성화되기 전엔 일반적인 AT모뎀 처럼 동작해야했기에,
유저 인터페이스는 tty 로 만들어주고,
GPRS 가 활성화된 후 네트웍과 기타등등을 모두 커널 모드에서 별도 장치 드라이버로 빼기 위해...
ldisc 가 아니라 다른 방법을 사용하셨던 것 같습니다.
제 기억엔 /dev/ttyXX 를 filp_open() 해서 vfs_read/write 를 사용하셨던 것으로 기억합니다.
vfs_read() 로 패킷 받아서 헤더 까보고 데이터만 각 장치로 나눠주고,
각 장치에서 올라온 데이터에 헤더 적절히 붙여서 vfs_write() 하는 걸 봤던 기억이 납니다.
각설하고,
tty_struct.ops->write() 는 있는데 read() 는 어딨느냐는 뜻의 질문인가요 ?
ldisc.receive_buf 콜백이 그 역할을 합니다.
receive 는 디바이스 쪽에서 발생하는 이벤트이므로 드라이버 측에서는 콜백을 제공하는 게 자연스럽지 않습니까 ?
ldisc.receive_buf 콜백
개발한 ldisc 드라이버의 ldisc.receive_buf 함수를 통해서 user-space 까지는
데이터가 정상적으로 올라가는 것을 확인하였습니다.
"receive 는 디바이스 쪽에서 발생하는 이벤트이므로 드라이버 측에서는 콜백을 제공하는 게 자연스럽지 않습니까 ?"
위에서 말씀하신 이 부분이 저도 지금 애매하더라구요.
코드 분석을 해보니 irq를 통해서 receive_buf 함수가 호출되는 것으로 확인했습니다.
그렇기에 직접 receive_buf함수를 호출은 할 수 없을거 같아서요.
그럼 이때 irq를 통해서 irq handler에 의해서 callback함수로 새로 구현한 receive_buf 함수를 등록해줘서
해야 하는가 의문이 들고요. 추가적으로 이때 사용할려는 irq는 이미 tty framework에서
사용되는 부분이라서 어떻게 사용을 해야하는지에 대해서 의문점이 들어서요.
즐거운 하루 되세요. 최찬우입니다.^^
"누가 어디로부터 뭘 read" 해야하는 건지 정리
"누가 어디로부터 뭘 read" 해야하는 건지 정리 좀 해주세요.
왜 'user-space 까지는 데이터가 정상적으로 올라가는 것을 확인' 해야 하는지 궁금합니다.
제 기억에, 이게 되려면 ldisc.read() 를 작성하셔야 가능합니다.
게다가 ldisc.receive_buf() 에서 받은 데이타를 어딘가에 보관하고 ldisc.read() 가 그걸 읽어가야하죠.
이걸 하셨다면, 왜 다른 커널 모드 드라이버로 데이타를 넘기는게 헷갈리시나요 ?
똑같이 어딘가에 보관하고 있다가 다른 커널 모드 드라이버가 읽어가게 하던가,
다른 커널 모드 드라이버의 특정 함수를 호출해서 데이타를 넘겨주던가 하면 되는데요.
혹 ttyS0 를 타겟으로 삼아 ttyVS0~4 같은 가상의 장치를 만드는 게 목표인가요 ?
드라이버가 두 개 필요합니다.
mux/demux(혹은 duplicate)를 담당할 ldisc 드라이버와 유저 입출력을 담당할 ttyVS 드라이버.
ttyVS 드라이버는 실제 장치대신 작성하신 ldisc 드라이버와 데이타를 주고 받고,
유저와 ttyVS 드라이버 사이엔 기존의 n_tty ldisc 가 사용됩니다.
read함수 구조
제가 read 함수 구조를 이해하지 못하고 있었네요.
comment 주신 내용을 토대로 read함수 구현하였습니다.
자세한 답변 감사드립니다.
오전에 이어 눈이 또 내리기 시작하는데 눈길 조심하세요.^^
즐거운 하루 되세요. 최찬우입니다.^^
댓글 달기