在Linux内核中的UART轮询期间处理CTRL-C

Question

I have a syscall read, like so:

ssize_t serp_read(struct file *filep, char __user *buf, size_t count, loff_t *offp){
        ssize_t cnt;
        char *buffer;
        int i;

        buffer = kmalloc(count * sizeof(char), GFP_KERNEL);

        for (i = 0; i != count; ++i) {
            buffer[i] = UART_read();
            if(buffer[i] == '\n')
                break;
        }

        cnt = copy_to_user(buf, buffer, i);
        kfree(buffer);
        if(cnt) {
        printk("Error in copy_to_user() cnt is %d\n", cnt);
        i -= cnt; /* bytes successfully copied */
        }

        return i; 
}

And the UART_read() is

unsigned char UART_read(void){
     unsigned int buf;
     if( ( inb(UART + UART_LSR) & UART_LSR_FE ) == 1){
       printk("KERNEL - Framing error"); return -1;}
     else if( ( inb(UART + UART_LSR) & UART_LSR_PE ) == 1){
       printk("KERNEL - Parity error"); return -1;}
     else if( ( inb(UART + UART_LSR) & UART_LSR_OE ) == 1){
       printk("KERNEL - Overrun error"); return -1;}

     while( ( ( inb(UART_LSR + UART) ) & UART_LSR_DR ) == 0 ){
             schedule();
     }
     buf = inb(UART);
     return (char)buf;
}

And in my test program I invoke it

    rb = read(fd, buffer, sizeof(buffer));
    if ( rb < 0){
        perror("Error");
    }
    else {
        buffer[rb] = '\0';
    }

So, from the moment I invoke it in the test program, I can't get out unless the UART gets some characters. But I want to be able to interrupt the process. Can I do a normal handler to handle a CTRL-C? Or do I have to do something different for the same effect? And if the handler is called, where is the kernel program going to go afterwards? Or what would happen in the kernel if I just had a normal handler in the test program? Would it work at all?

Also, kernel code is one program and the test program is another program altogether.

Answer 1

EDIT2: ctrl+c issues a signal(SIGINT) that can be treated with sigaction()

-----------IGNORE MODE ON (according to @undefined-behaviour)-------------

this code handles a ctrl+c

EDIT: while ((a!='A')&&(a!= 'ctrl+c' )); this was supposed to have the 'ctrl+c' char but stackoverflow doesnt show it (its the decimal/octal/hex: 0003)

#include <stdio.h>
#include <unistd.h> /*_getch*/
#include <termios.h>    /*_getch*/


char getch() {
    /*#include <unistd.h>   //_getch*/
    /*#include <termios.h>  //_getch*/
    char buf=0;
    struct termios old = {0};
    fflush(stdout);
    if(tcgetattr(0, &old) < 0)
        perror("tcsetattr()");
    old.c_lflag&=~ICANON;
    old.c_lflag &= ~ECHO;
    old.c_cc[VMIN]=1;
    old.c_cc[VTIME]=0;
    if(tcsetattr(0, TCSANOW, &old) < 0)
        perror("tcsetattr ICANON");
    if(read(0,&buf,1)<0)
        perror("read()");
    old.c_lflag=ICANON;
    old.c_lflag=ECHO;
    if(tcsetattr(0, TCSADRAIN, &old) < 0)
        perror ("tcsetattr ~ICANON");
    printf("%c\n",buf);
    return buf;
}

int main(int argc, char *argv[]){
    char a;
    do{
        a=getch();
        printf("%d-%c \n",a,a);
    }while ((a!='A')&&(a!='ctrl+c'));   /* ctrl+c ;  backspace ;� multi-char cte ; ç 135*/
    printf("\n");
    return 0;
}

Answer 2

I believe what you can do is write a signal handler at your application level which catches SIGINT (ctrl+c) or whatever signal of your choice (provided we can handle those)

and from the signal handle call an IOCTL call to your driver inside kernel which inturn should reschedule your kernel read may be a change in logic like below

you need to implement an IOCTL call at kernel along with this

 /** This NO_SIGNAL_FROM_USER is a GLOBAL variable at kernel 
             which should be set based on your IOCTL**/

 while( (( ( inb(UART_LSR + UART) ) & UART_LSR_DR ) == 0 ) && (NO_SIGNAL_FROM_USER)){
             schedule();
     }

and a little change at your read

for (i = 0; i != count && NO_SIGNAL_FROM_USER ; ++i) {
            buffer[i] = UART_read();
            if(buffer[i] == '\n')
                break;
        }
/*** RESET THE SIGNAL HERE AGAIN ***/

PS - oops forgot may be you need to do some more handling at signal handler also in your user application, but again that depends i guess.